System design interview questions, grouped by concept

"Design Twitter" and "design a notification service" sound unrelated. Both turn on the same question: when one event has to reach many people, do you do the work when it's written or when it's read? Once you see that, the second prompt stops being new. Memorized answers fall apart the moment the interviewer changes a requirement. A concept lets you reason from the requirement you were just given.

The order matters more than the exact timings. Freezing halfway through usually means you started drawing before you knew what you were building.

1. Requirements, about five minutes. Ask what the system must do, for whom, and what can be left out. Agree the two or three features you'll design and say out loud what you're dropping.
2. Scale, about five minutes. Rough numbers for users, requests per second, data size and read-to-write ratio. Round hard. The point is to find out which part of the system is under pressure, not to get the arithmetic right.
3. API and data model, about five minutes. The handful of calls clients make, and the main entities with their keys.
4. High-level design, about ten minutes. The request path end to end, with the simplest design that meets the requirements.
5. Deep dive, about fifteen minutes. The one or two hard parts the scale estimate pointed at. This is where most of the signal is.
6. Failure and trade-offs, the last five minutes. What breaks, what you'd monitor, and what you'd change with more time or a different requirement.

The interviewer will steer. Go where they steer, and come back to the structure when they let go.

This prompt looks like a simple CRUD app and isn't. It is mostly concept 3, contention, with some of concept 1 for browsing.

Requirements

Ask first. Specific seats or just a section? Is payment in scope? Say we agree: users browse events, pick specific seats, hold them while they pay, and either complete the purchase or lose the hold. Payment is an external provider. Resale and refunds are out, and you say so.

Scale

Most days, traffic is light and read-heavy. On sale day for a big show, far more buyers than seats arrive within minutes. The exact numbers matter less than that shape. It tells you the hard part isn't storage. It's thousands of people grabbing the same few rows in the same second.

API and data model

Three calls carry the design: get the seat map, hold a set of seats, confirm a booking with a payment reference. The core table is seats, keyed by event and seat ID, with a status (available, held, sold), the holder and a hold expiry.

High-level design

Seat maps are read far more than they change, so browsing goes through a cache; a few seconds of staleness is fine because the real check happens at hold time. Holds and bookings go to a single relational database, the source of truth for seat status. The payment provider confirms by callback.

Deep dive: two people, one seat

This is where the interview is won or lost. To hold a seat, the service runs a conditional update: set the status to held, with this user and an expiry, only where the status is currently available. For example, UPDATE seats SET status = 'held', holder = ?, expires_at = ? WHERE event_id = ? AND seat_id = ? AND status = 'available'. If the update touches zero rows, someone else got there first, and the user is told immediately. For several seats at once, do it in one transaction and roll back if any seat fails, so nobody ends up holding half a row.

Holds expire. A background job, or a check at read time, returns expired holds to available. The expiry should be generous enough to finish payment and short enough that abandoned carts don't lock up the show.

For the sale-day spike, put a waiting room in front of the booking path: admit users in batches at a rate the database can handle and show everyone else their place in the queue. That protects the database and it's fairer than letting the fastest retry loop win.

Confirmation has to be safe to retry. The confirm call carries an idempotency key, and the service checks the hold is still owned by this user and not expired before marking seats sold. If payment succeeds after the hold expired, you either honor it when the seat is still free or refund automatically. Saying which, and why, is a trade-off the interviewer will want to hear.

Failure and trade-offs

Name what you'd watch, such as hold success rate and payments that arrive after expiry, then the trade-off you made on purpose. One database for seat status limits write throughput, but it makes double-selling much easier to rule out. If the interviewer pushes on scale, partition by event: seats in different shows never contend.

The prompts are often the same at both levels. What changes is what the interviewer is listening for. Levels and titles vary between companies, so treat this as a direction rather than a rubric.

Public career ladders show the shape of the difference. In Dropbox's engineering career framework, the level below staff (IC4) reads "I own and deliver semi-annual/annual goals for my team," and staff (IC5) reads "I deliver multi-year, multi-team product or platform goals." In a design round, that difference in scope is what you're demonstrating.

At senior level, the bar is a sound design you drive yourself: scoped without being led, trade-offs made for stated reasons, depth on the hard component when asked. The walkthrough above, done cleanly and on time, is a senior answer.

At staff level, that design is the starting point. Question the framing: does every event need a seat-level map, or only some venues? Talk about how the system rolls out alongside what exists today, which teams it touches, what it costs to run, and what you'd deliberately not build yet. Bring up operations before you're asked, and say which parts you'd want another team's view on.

The common mistake at staff level is giving a very good senior answer and stopping there. The common mistake at senior level is trying to sound staff by talking about org structure instead of finishing the design.

Engineering manager loops often include a design round too, judged with more weight on the trade-offs and the people around the system than on the details. The engineering manager interview guide covers how that round differs.

Read less and talk more. Pick a prompt, set a 45-minute timer, and design it out loud with a whiteboard or a blank document, following the structure above. Then go back and ask which concept it tested and whether you spent your deep-dive time on it. Doing that with one prompt per concept covers more ground than reading fifty solutions.

Loops differ in what they emphasize, so before a specific interview, check the guide for that loop, for example the Google software engineer guide or the Anthropic infrastructure engineer guide.

You will, eventually. Ask the requirements questions anyway, then ask yourself which of the six concepts the scale points at. If the answer is "more than one," pick the one that would hurt most to get wrong and say that's where you'll spend your deep dive. Naming the concept out loud tells the interviewer you know where the difficulty is, and that's most of what they're trying to find out.