The 7-Step System-Design Walk-Through
A repeatable interview framework — clarify, estimate, contract, high-level, data, detail, evaluate. Read this first; every system writeup on this site follows it.
Summary#
A 45-minute system-design interview is a structured conversation, not a free-form brain-dump. The seven steps below convert “design X” into a sequence of decisions an interviewer can grade. Every system page on this site uses the same step numbering, so once you’ve internalised the rhythm you can recognise the shape of an answer at a glance.
Why it matters#
Most candidates lose the interview in the first ten minutes — not because their architecture is wrong, but because they started designing before they knew what they were designing. The interviewer is silently grading two things simultaneously: the design itself, and the candidate’s ability to navigate ambiguity. A repeatable structure addresses both.
A senior interviewer can drop the candidate into any system (Twitter, Uber, ChatGPT) and watch the same seven beats. When a step is skipped — usually capacity estimation or the evaluation step — that’s a flag for the level decision later.
How it works#
The framework is a strict order on the opening of the interview, and a loose order on the rest. Steps 1–3 (Clarify → Estimate → Contract) should run in that order with minimal backtracking. Steps 4–6 (High-Level → Data → Detail) often interleave once a sketch is on the whiteboard. Step 7 (Evaluation) closes the loop and is where most signal happens.
Step 1 — Clarify Requirements#
Don’t trust the prompt. “Design Twitter” hides at least a dozen invisible choices: are we designing the timeline or the upload pipeline? Mobile-first or web-first? Public or private accounts? Global or region-locked?
Surface 4–6 questions that you’d ask a PM. Distinguish functional requirements (what the system does) from non-functional requirements (how well — availability, latency, throughput, durability). Write the agreed-on subset on the board. This is the scope contract for the rest of the interview.
Step 2 — Capacity Estimation#
Order-of-magnitude back-of-envelope math. Pick numbers like “100M DAU, 10 posts/day each, 100 KB per post” and compute QPS, storage/year, bandwidth. The math is rarely the answer to anything — but it tells you which problems are real (e.g. “we’ll need to shard this”) and which are fake (e.g. “a single MySQL is fine”).
Show the work. Interviewers want to see the conversion chain (DAU → QPS → bytes/sec). Wrong numbers with right reasoning beat right numbers without reasoning.
Step 3 — System Interface#
What does the API look like from the outside? A handful of endpoints with their request/response shapes. Mark which are idempotent, which are bulk, which are streaming. This anchors the rest of the design: every subsequent component must serve one of these endpoints.
Step 4 — High-Level Design#
Boxes and arrows. Aim for 6–10 boxes maximum. The drawing should fit on a whiteboard with room to annotate. Identify the major services (web, application, cache, primary DB, async worker, queue, CDN) and the data flow between them. Don’t draw what you don’t plan to discuss.
Step 5 — Data Model#
Schemas, partitioning keys, hot-row analysis. This is the step that most newcomers skip — and it’s the step that frequently determines the entire system shape. If the partition key is wrong, you’ll be re-doing the design at 10x scale.
Step 6 — Detailed Design#
The interviewer will pick 2–3 components from your high-level sketch and ask “tell me more about this one”. Zoom into each, draw the internal architecture, talk about the trade-offs. This is where 40% of the time goes.
Step 7 — Evaluation & Trade-offs#
Close the loop. What are the bottlenecks? What would break first? What did you not choose and why? What would you push back on if a PM demanded it?
A strong candidate volunteers two or three failure modes the interviewer was about to ask about, and proposes guardrails. A weak candidate says “looks good to me” — and watches the interviewer drill in until something cracks.
Variants and trade-offs#
The structure is a tool, not a doctrine. Senior candidates often skip steps the prompt has already answered (capacity estimation for a small admin tool) or fold steps together (data model alongside high-level when there’s no separation worth the time).
When this is asked in interviews#
Always. Even if the interviewer doesn’t ask “walk me through your framework”, they’re grading against this implicit scaffold. The bigger the company and the more senior the role, the more weight on steps 1 (clarification) and 7 (evaluation) — those are where signal lives.
Related concepts#