System Design · Architecture under constraints
How do you structure a system design interview answer?
Short answer
Clarify functional and non-functional requirements, estimate scale, sketch the API and data model, then design the high-level path before deep-diving bottlenecks and trade-offs.
A system design interview is a structured conversation, not a memory test. The interviewer is checking whether you can turn an ambiguous prompt into explicit requirements, make assumptions visible, and justify architecture choices against measurable constraints.
A reliable sequence
- Clarify scope: core use cases, out of scope, clients and read/write mix
- Turn non-functional needs into numbers: p99 latency, availability, durability, retention
- Estimate scale: peak QPS, payload size, storage growth and fan-out
- Define the API and the primary data model before drawing components
- Sketch the happy path end to end, then deep-dive the riskiest component
- Close with failure modes, bottlenecks, cost and alternatives you rejected
State assumptions out loud and write them down. If the prompt says a social app, say you assume 50 million daily users, a 10:1 read-to-write ratio and a p99 feed latency under 300 milliseconds. The exact numbers matter less than showing that the design follows from them and that you can revise when the interviewer changes a constraint.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How much time do you spend on requirements before drawing anything?
- 2What if the interviewer wants you to start designing immediately?
- 3How do you decide which component deserves the deep dive?
- 4How do you close the interview when time runs out?
Say it in the interview
I start by narrowing scope and turning vague qualities into numbers, because those numbers drive every later choice. Then I estimate peak load, define the API and data model, and walk the happy path before deep-diving the riskiest part. I keep assumptions explicit and finish with failure modes and the trade-offs I rejected. The goal is to show reasoning, not to reproduce a known diagram.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.