How to structure a system design interview

1. What the framework is

A system design framework is a fixed order of stages you apply to any open prompt, from "design a URL shortener" to "design WhatsApp". It is not a script. The interviewer will interrupt, redirect and probe, and the framework is what lets you get back to where you were. It exists because every prompt is far too large for 45 minutes, so the real task is choosing what to build, what to skip, and saying so out loud.

2. Why interviewers care about structure

There is no single correct answer to a design prompt, so the interviewer grades how you get to one. Rubrics differ between companies, but most look for the same things: you explore the problem before solving it, your choices follow from requirements and numbers, you can name what each choice costs, and you can go one level deeper when asked.

Structure makes those signals visible. A candidate who jumps straight to boxes and arrows may know all the right components, but the interviewer cannot see why they were chosen. A candidate who works in order leaves a trail the interviewer can write up afterwards, which matters because the write-up, not the conversation, is what the hiring committee reads.

3. The 45-minute plan, stage by stage

1. 1RequirementsAsk who uses the product, which features matter and at what scale. Write functional requirements (what it does) apart from non-functional ones (latency, availability, durability, consistency). End with an explicit out-of-scope list: it protects you later when the interviewer asks about something you chose not to build.
2. 2EstimatesTurn users into requests a second, storage and bandwidth, with every figure labeled as an assumption. The goal is to find the bottleneck: reads, writes, storage, or fan-out. See capacity estimation for the arithmetic.
3. 3APIName the calls that carry the product, such as POST /messages and GET /conversations/{id}/messages?before=. Pagination, idempotency keys and authentication are worth one sentence each here, because they come back in the deep dive.
4. 4Data modelList the entities and, for each, how it is read: by primary key, by range, by search. The access pattern decides the store and the partition key, so say it before choosing a database. See SQL vs NoSQL.
5. 5High-level designDraw the simplest design that meets the requirements and walk one request through it, then the other main request. Only add a cache, a queue or a replica when you can say which requirement or number needs it.
6. 6Deep divesPick the one or two parts that make this product hard and go into detail: the schema, the partition key, the algorithm, the retry policy. Offer a choice ("I can go deeper on fan-out or on storage; which is more useful?"), because many interviewers have a part they want to see.
7. 7Trade-offs and failure modesFor each major component, say what happens when it dies, when traffic grows tenfold, and what you would have done with different requirements. Name the alternative you rejected for each big choice.
8. 8Wrap-upSummarize in three sentences: the core design, the main trade-off, and what you would build next. Then ask your questions.

4. What to say at each stage

Short, explicit sentences turn your thinking into something the interviewer can write down. These are patterns, not lines to recite; put them in your own words.

5. What to do when you are stuck

Everyone stalls at some point. Silence is the costly part, not the stall itself. Work through these in order.

1. 1Say that you are thinking"Give me a moment to think about how to keep these counters consistent." A short, announced pause reads as care. A long, silent one reads as lost.
2. 2Go back to the requirementsMost dead ends come from solving a harder problem than the one asked. Re-read the list: does this feature really need strong consistency, or real-time delivery?
3. 3Start with the simplest version"The naive approach is one database table with a lock. That breaks at about this many writes, so let me improve it." A working baseline, then an improvement, is a perfectly good answer.
4. 4Reason from the numbersIf you cannot decide between two designs, ask which one the estimates rule out. Thousands of writes a second and millions are different systems.
5. 5Ask a narrow questionNot "what do you want me to do?" but "is it acceptable for a user to see a like count that is a few seconds stale?" A narrow question shows you have found the real decision.
6. 6Park it and move on"I will mark this as an open question and come back to it." Then do come back. Leaving one part open is far better than spending the whole deep dive on it.

6. What changes by level

Level names and expectations differ between companies, so treat this as a common pattern, not any one company's rubric. The same prompt can be a pass at one level and a miss at the next.

7. How the plan bends for common prompts

The order stays the same, but each prompt has its own hard part, and that is where the deep dive goes.

8. Mistakes to avoid

• Drawing before asking. Five minutes of questions saves twenty minutes of designing the wrong product.
• Estimates that go nowhere. If you compute storage, use it: "about 90 TB, so this has to be partitioned."
• Naming technologies instead of reasons. "Kafka" is not a design decision. "A durable queue so that slow consumers do not block the write path" is.
• Breadth with no depth. Fifteen boxes, none explained, scores worse than six boxes and one that you can take apart.
• Ignoring the interviewer's hints. A question like "what if this service is slow?" is usually a request to talk about exactly that.
• Treating it as a monologue. Check in every few minutes. The interviewer may be waiting to redirect you.
• No failure discussion. Leaving no time for what breaks is one of the most common reasons a solid design still misses the bar.

9. How to talk through it: a worked opening

The first five minutes set the tone for the whole round. Here is an opening for a notification system prompt that covers scope, estimates and the plan in about three minutes of speech.

A checklist to print

[ ] Restated the prompt in one sentence
[ ] Functional requirements written down
[ ] Non-functional targets: latency, availability, durability, consistency
[ ] Out-of-scope list agreed
[ ] Assumptions labeled: users, actions a day, object sizes
[ ] Average and peak requests a second, read/write ratio
[ ] Storage over the retention period, bandwidth
[ ] Two to five API calls, with idempotency where retries happen
[ ] Entities, keys and the access pattern for each
[ ] One request traced end to end on the diagram
[ ] Every cache, queue and replica justified by a number or requirement
[ ] One or two deep dives, chosen with the interviewer
[ ] For each big choice: the alternative and its cost
[ ] Failure of each main component, and a tenfold traffic increase
[ ] Three-sentence summary and your questions

Practicing with Natively

The framework only becomes automatic through spoken practice. Run a mock interview with a friend on a call, or read a prompt aloud and answer it as if someone were listening. Natively transcribes the conversation live and can suggest talking points for each question as it comes in; comparing them with what you said is a quick way to spot gaps such as failure modes or the out-of-scope list. If you sketch a diagram or capture a problem statement, it can explain the screenshot. Afterwards, the transcript and notes are kept for review, so you can check how long each stage really took.