How to run a system design interview, step by step

The shape of the hour

Candidates rarely fail because they have not heard of sharding. They fail because forty minutes in, they are still talking about things nobody asked for, and the interviewer has no evidence they can make a decision.

Budget the time out loud at the start. Interviewers like it, because it tells them you have done this before. Adjust for a 45 or 60 minute slot, but keep the order.

1. 0 to 5 min Requirements. Functional first, then non-functional, quantified.
2. 5 to 8 min Core entities. The nouns your system stores and exchanges.
3. 8 to 13 min The API. The contract before the boxes.
4. 13 to 30 min High level design. Simple, and meets the functional requirements.
5. 30 to 45 min Deep dives. Where the non-functional requirements get satisfied.

The single most common failure is starting to draw boxes at minute three. Everything before the high level design exists so that the boxes are the right boxes.

Functional requirements: pick three

Write them as "users should be able to". Keep them targeted.

The system you are asked about probably has hundreds of features. Your job is to identify and prioritise the top three, because the rest of the interview is judged on whether your design meets the requirements you chose.

Say the ones you are cutting out loud. "I am going to leave direct messages and search out of scope so I can do the feed properly" is a stronger move than silently ignoring them, and it invites the interviewer to correct your priorities early, while it is cheap.

Non-functional requirements: quantify or skip

"The system should be low latency" is not a requirement. Almost every system should be low latency, so it tells the interviewer nothing and constrains your design not at all.

"Search should return in under 500ms at the 99th percentile" is a requirement. It names the part of the system that has to be fast, and it gives you a number to design against and to check yourself against later.

Two things make a non-functional requirement useful: it is put in the context of this system, and where possible it carries a number.

• Fault tolerance. What is allowed to fail, and what happens when it does.
• CAP. Under a partition, do you choose consistency or availability. Say which, and for which operation, because the answer is often different for reads and writes.
• Compliance. GDPR, HIPAA, PCI, data residency. Rare in interviews, decisive when it applies.
• Scalability. How many users, how much data, how much growth.
• Latency. Which operation, what number, at what percentile.
• Environment. Mobile clients on bad networks, embedded devices, browser limits.
• Durability. What must never be lost. A tweet and a payment have different answers.
• Security. Authentication, authorisation, tenant isolation.

A mnemonic that survives interview nerves: FCC and SLEDS. Fault tolerance, CAP, Compliance, then Scalability, Latency, Environment, Durability, Security. You will not need all eight. Running the list takes fifteen seconds and stops you forgetting the one that mattered.

Capacity estimation: do it when it changes a decision

Tell the interviewer you would rather skip estimation upfront and do the arithmetic while designing, when and if it changes something. Most interviewers welcome this, because upfront estimation is usually a ritual that produces numbers nobody uses.

Then actually do it when it matters. Designing a top-K system for trending topics? Estimate how many topics you expect, because that decides whether one min-heap on one instance is enough or whether you have to shard it, and that changes the whole design.

The test is simple: if the number would change a box on the board, compute it. If it would not, skip it.

The numbers worth memorising

You need very few. These are the ones that come up, and knowing them lets you do arithmetic out loud instead of hedging.

Latency, in numbers you can multiply

Read these as orders of magnitude, not as benchmarks. The ratios are the part you use.

The useful conclusion: a cross-region round trip costs roughly as much as reading 600MB from memory. That is why chatty cross-region calls destroy a design and why a single round trip that fetches everything usually beats five that each fetch a little.

Sizes, so storage maths is quick

Worked example. One million users each upload ten high resolution photos. That is 10 million photos at 1MB, so 10TB before replication. At three replicas it is 30TB. Now you know whether this is a single database question or an object storage question, and you got there in one sentence.

Core entities

These are the nouns your API exchanges and your system stores. Name them before you design anything, because they are what the API and the data model are both made of.

For Twitter they are unglamorous: User, Tweet, Follow. That is the point. If your core entities look complicated this early, you have probably imported a solution into a problem.

• Who are the actors? And do any of them overlap. A driver and a rider may be one User entity or two.
• What nouns are needed? Go back through your functional requirements and pull out the resources each one needs.

The API: the contract before the boxes

Define what your system offers before you design how it works. For product style questions this usually maps straight from the functional requirements you already chose.

• REST. HTTP verbs over resources. Your default. Choose it unless you have a reason not to, and say why you chose it.
• GraphQL. When clients are diverse and want different shapes of the same data, and over-fetching is a real cost. Mobile clients on poor networks are the usual justification.
• RPC, such as gRPC. Action oriented and faster for service to service traffic. Internal APIs where performance matters, not your public edge.

Never take the current user from a request body or a path parameter. Derive it from the auth token. An interviewer who sees POST /follows with a follower_id in the body has just watched you build an authorisation bug, and it is one of the fastest ways to lose a senior signal.

What a good API sketch looks like

Plural resource names, no user ids in bodies where auth should supply them, and a shape for what comes back.

Data flow, only if you have one

Some systems, especially data processing ones, are best described as a sequence before they are described as boxes. A web crawler is: fetch seed URLs, parse HTML, extract URLs, store data, repeat.

If your system is not a pipeline, skip this step. Do not perform it because it is on a list.

High level design

Build the simplest thing that meets your functional requirements. Not the scalable thing. The simple thing.

You will spot places for a cache or a queue while you draw. Note them out loud, write a word on the board, and keep going. Those are deep dive material, and reaching for them now is how people run out of time with no working design on the board.

Be explicit about how a request flows and what state changes. Start at the API call and finish at the response, and say what is written where. When you reach the database, that is the natural moment to write the important columns next to it, because the interviewer wants to know whether you have thought about the data model at all.

Say the shortcut out loud. "I am going to read the feed straight from the tweets table for now, which will not hold at scale, and I will come back to it in the deep dives." You have shown you can see the problem without spending ten minutes on it yet.

Deep dives

Now you harden it. Your simple Twitter design fetches feeds in a way that falls over, and that is fine, because this is the part where you fix it.

Four things to spend the last stretch on, roughly in this order.

• Meet your non-functional requirements. Go back to the numbers you wrote at the start and show how the design hits them. This is why quantifying them earlier was worth it.
• Address the bottleneck you already flagged. The one you noted out loud during the high level design. Returning to it deliberately reads as control.
• Handle the edge cases. The hot key, the celebrity account, the retry storm, the partial failure.
• Follow the interviewer. Their probes are the actual rubric. If they keep asking about consistency, consistency is what they are scoring.