In this article
How to use this page
Treat each answer as the opening 30 seconds of a design round, not the whole round. The round itself is described in the distributed systems interview guide: clarify the problem, sketch the parts, then go deep where the interviewer pushes. Questions here are written in our own words from questions that candidates reported; a company name is never evidence that the company asks it. Where a fact comes from vendor documentation it is linked and dated, and where a number is an assumption it is marked as illustrative, because a design answer should show its arithmetic, as in back-of-the-envelope estimation.
Online judge: design LeetCode
What technologies would you use to design LeetCode, and what are you optimizing for?
A strong answer names the goals first: correct verdicts, safe execution of untrusted code, fair timing, and a scoreboard that stays responsive during a contest. Then split the system: a web service for problems and users, a queue of submissions, a pool of judge workers that run code in isolation, a store for results, and a log of user actions. Say what you trade: a queue adds delay but absorbs a contest spike.
Why it is asked: it checks whether you pick goals before tools. Related: the distributed systems guide.
How do you run untrusted submitted code safely?
Run each submission inside a sandbox, which is an isolated environment that limits what a program can read, write and consume. A sound design gives each run its own container or similar boundary, no network, a limit on central processing unit (CPU) time, a limit on memory and output size, and a wall-clock timeout, then destroys the environment afterwards. Plain containers share the host kernel, so strong judges add system-call filtering or a microVM or gVisor-style boundary. Judge workers pull jobs from the queue, so one slow submission cannot stall the website.
Why it is asked: it separates candidates who think about security from those who only draw boxes. Related: backend interview questions.
How would logging work for every user action at large scale?
Treat actions as events written to a durable log. Apache Kafka stores events in topics that many producers can write and many consumers can read, and events are not deleted on consumption but kept for a retention period you configure (Apache Kafka documentation, accessed October 2026). Size it: with ten million daily active users making a hundred actions each (illustrative), that is one billion events a day, about 11,574 per second on average and 57,870 at a five-times peak.1
Why it is asked: it tests estimation plus a log-based pipeline. Read the full explanation: ad click aggregator and logging pipeline.
How do you keep the log ordered and sized for that load?
A partition is one ordered slice of a topic, and a topic is spread over several partitions on different brokers. Kafka keeps order only inside a partition, not across the topic, per the Kafka documentation, so choose a key, such as the user identifier, when per-user order matters. At 500 bytes an event (illustrative) the peak is about 28.9 megabytes per second, which needs six partitions at an assumed five megabytes per second each, and a seven-day retention holds about 3.5 terabytes.1
Why it is asked: it checks that you know where ordering stops. Related: ad click aggregator and logging pipeline.
How do you support many concurrent contests?
Separate the heavy path from the read path. Submissions go through the queue and judge workers, which can scale out when a contest starts. Scoreboards are read far more than written, so keep them in a fast store and update them as verdicts arrive, and rate-limit submissions per user so one contestant cannot flood the queue. Isolate contests, for example by queue or worker pool, so a large one does not slow the others.
Why it is asked: reported variants of this question stress concurrent competitions. Related: distributed rate limiter design.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Games, chess and leaderboards
How do you design Tic-Tac-Toe that is multi-user, distributed and fault tolerant?
Start with the state: a board is tiny, so the hard part is agreeing on whose move is next. Keep one authoritative game record per match, let each move be a request that carries the expected move number, and reject a stale or repeated move, so a retry after a failure cannot play twice. For fault tolerance, replicate the record and persist each accepted move before acknowledging it.
Why it is asked: a trivial game exposes how you handle concurrency and failure. Read the full explanation: concurrency interview questions.
How big is the Tic-Tac-Toe state space?
A three-by-three board has nine cells with three states each, so 3^9 = 19,683 raw boards; counting only positions reachable by legal play that stops at a win or a full board gives 5,478.1 Either number fits in memory many times over, so you can store the whole game, even every position, without any sharding. Say that out loud: the design problem is coordination, not size.
Why it is asked: it shows you size a problem before you scale it. Related: back-of-the-envelope estimation.
How do you design a real-time chess platform across devices?
Clients keep a persistent two-way connection, usually a WebSocket, to a game service, which holds the authoritative game and sends each move to the opponent. The server validates every move against the rules, so a modified client cannot force an illegal position, and writes it to storage before broadcasting. Devices only render state; reconnecting a device means fetching the move list and resuming. The same shape appears in chat systems.
Why it is asked: reported by candidates at a Staff level, it covers connections, validation and state. Related: chat system design.
How do matchmaking and leaderboards work?
Matchmaking pairs players of similar rating from a waiting pool, widening the allowed gap as the wait grows. For rankings, a sorted set is a Redis data type that keeps members ordered by score. The Redis documentation says calling ZADD on an existing member updates its score and position in O(log N) time, and ZRANK and ZREVRANK return a member's position (accessed October 2026). For ten million players (illustrative) that is about 23 levels of search.1
Why it is asked: it checks that you choose a data structure for the query. Source: Redis sorted sets.
How would move undo work?
Store the game as an append-only list of moves, not only the current board. An undo then becomes a new event that the opponent must accept, or a rule-limited request, and the board is rebuilt from the moves. The list also gives you replay, audit and recovery after a crash. Decide in the clarifying step whether undo is allowed in ranked games, since it changes the rules.
Why it is asked: it tests event-style state over mutable state. Related: database interview questions.
Search and reviews: design a Yelp-like app
How do you design a Yelp-like restaurant review app?
Name the core flows: browse and search places near a location, read a place page, and write a review with a rating. Sketch a place store, a review store, a search index for location and text, and a read-heavy cache for popular pages. Reads vastly outnumber writes, so optimize reads and accept that a new review shows up in averages a little later.
Why it is asked: reported by candidates, it is a read-heavy product design. Related: database interview questions.
How do you find restaurants near a user?
Divide the map into cells and index places by cell, so a query looks at the user's cell and its neighbors instead of scanning every place. Common choices are a geohash grid or a quadtree, or a database with spatial indexes; then sort the few hundred candidates by distance and filters such as cuisine. State the trade-off: cells are fast but need neighbor handling at borders.
Why it is asked: it tests whether you turn a geometric question into an index lookup. Related: database interview questions.
How do you keep a place's average rating current?
Do not recompute the average from every review on each read. Keep a running count and sum per place and update them when a review is written, in the same transaction as the review, or recompute from a queue if you accept a short delay. Edits and deletions then adjust the sum by the difference. Decide whether a user may review a place more than once.
Why it is asked: it probes write-time against read-time computation. Related: database interview questions.
Account flows: forgot password
What happens after someone clicks the forgot-password button?
The user submits an email address; the service replies with the same message whether or not an account exists, then, if one does, sends a link carrying a random, single-use, expiring token. Opening the link shows a form, the token is checked, and only then is the password changed and old sessions ended. Nothing about the account changes before a valid token arrives. The authentication chapter of the OWASP Application Security Verification Standard (ASVS) (version 4.0.3, section V2.5, credential recovery) is the reference for recovery flows; its requirement 2.5.6 asks that forgotten-password and other recovery paths use a secure recovery mechanism. The steps above are design reasoning, not quoted requirements.
Text description of the diagram
- The reply is the same whether or not the account exists.
- The token is random, single use and expiring.
- The account changes only after a valid token is presented.
Why it is asked: reported by candidates for a streaming service, it tests security thinking inside an everyday flow. Related: backend interview questions.
How do you handle the edge cases in a password reset?
Cover four cases. A reply that differs for unknown emails lets attackers list who has an account, so keep the reply identical, with the same response time. A guessable token is a takeover, so generate it with a cryptographically secure random source, store only a hash, make it single use and expire it. Locking an account on every request lets anyone lock anyone out, so change nothing until a token is presented. Limit how many requests one account or address can make. These controls are design reasoning for the kind of flow that section V2.5 (credential recovery) of the OWASP ASVS authentication chapter covers, not a list of that standard's requirements.
Why it is asked: each edge case is a known attack, and naming it shows experience. Related: rate limiter design.
Scheduling and booking
How would you design an elevator system?
Model an elevator with a current floor, a direction and pending stops, and a controller that receives requests. Score each elevator by cost: one heading that way and passing the floor is cheapest, an idle one costs its distance, one moving away costs most. A scan policy keeps one direction, serving stops, then reverses. From floor five moving up with calls at eight, three, ten and two (illustrative), it serves eight, ten, three, two.1
Why it is asked: reported across companies, it checks object modeling and a clear policy. Related: backend interview questions.
How do you design a meeting room booking system?
Keep rooms and bookings, each booking holding a room, a start and an end. A new booking conflicts when its start is before an existing end and the existing start is before its end. Nine to eleven against ten to twelve overlaps; nine to ten against ten to eleven does not, because ends are exclusive (illustrative).1 Search rooms with no conflicting booking at the requested time and filter by capacity.
Why it is asked: it is a small design that must end in working code, reported by candidates with a one-hour limit. Related: database interview questions.
How do you stop two people booking the same room?
Let the database decide. Check and insert inside one transaction with a lock on the room, or declare a constraint that rejects overlapping ranges for the same room (in PostgreSQL, an exclusion constraint on a range type), and handle the rejection by telling the second user the slot is gone. An application-level check alone fails when two requests read the room as free together. For money-bearing bookings, see payment system design.
Why it is asked: it separates a check from an enforced rule. Read the full explanation: database interview questions.
How do you keep booking history and support different scheduling rules?
Never delete a booking: mark it canceled and keep it, so past records stay queryable. For rules such as recurring meetings, working hours or priority, define a small interface that takes a request and the current bookings and returns accept or reject, then plug in each rule behind it. The code then adds a rule without changing the booking core.
Why it is asked: it tests abstraction, which the reported question asks for explicitly. Related: database interview questions.
Follow-up questions
Does Kafka keep the order of all events in a topic?
No. Kafka keeps order within one partition only, per the Kafka documentation (accessed October 2026); events with the same key go to the same partition, so choose the key to match the order you need.
Does a message queue delete events once they are read?
Not in Kafka. Events can be read as often as needed and are discarded only after the retention period you set for the topic, so the log can serve as an audit trail.
Should a forgot-password page say that an email is not registered?
No. A different reply for unknown emails lets an attacker test which addresses have accounts; reply the same way every time and let only the email reveal the outcome.
Geohash or quadtree for nearby search?
A geohash turns each map cell into a string prefix, so ordinary indexes work, but a search must also check neighboring cells at borders. A quadtree splits crowded areas into finer cells, which suits uneven density, but the tree must be built and maintained. Either choice works if you state the trade-off.
- Pick goals first, then split into queue, workers, store and log.
- Kafka keeps order per partition, retains events by policy, and a key chooses the partition.
- A sorted set gives rank and score updates in logarithmic time.
- Password reset: identical reply, random single-use expiring token, no change before the token.
- Enforce booking rules in the database, not only in application code.
Sources
- Apache Kafka introduction (Apache Kafka documentation) — Apache Software Foundation, 26 Oct 2026
- Redis sorted sets (Redis Docs) — Redis, 26 Oct 2026
- OWASP ASVS 4.0.3, V2 Authentication chapter (section V2.5 Credential Recovery) — OWASP, 26 Oct 2026
- PostgreSQL documentation: range types and exclusion constraints — PostgreSQL Global Development Group, 26 Oct 2026
