The system design interview is the round most mid-to-senior engineers prepare for badly. They memorise a URL shortener design, recite it under pressure, and get a "no hire" because the interviewer was scoring something else. What is measured is how you think when the problem is deliberately underspecified.
What the interviewer is actually scoring
Nobody expects a production architecture in 45 minutes. The scorecard is closer to this:
- Structured thinking. Can you take a vague prompt and impose an order on it, out loud, so the interviewer can follow you?
- Requirement clarification. Do you ask what the system must do before deciding how it does it?
- Explicit trade-offs. Every choice costs something. Do you name the cost, or present decisions as free?
- Knowing when to stop. Do you keep optimising a component that is not the bottleneck, or move on?
Reciting a memorised architecture hurts you. It signals you cannot adapt when the interviewer changes a constraint, which they will.
The 45-minute budget
Time management is a scored skill, not an administrative detail. A workable split:
- 5 min: clarify and scope. Who uses this, what are the core operations, what is explicitly out of scope.
- 5 min: back-of-envelope estimation. Traffic, storage, read/write ratio.
- 10 min: high-level design. Boxes, arrows, data flow. Nothing deep yet.
- 15 min: deep dive. The interviewer picks one or two components. This is where most of the signal lives.
- 5-10 min: bottlenecks, failure modes, wrap-up.
Say the plan out loud at the start. "I want to spend about five minutes on requirements, then estimate, then sketch the high level, then go deep wherever you want." That single sentence already demonstrates structure.
Write the requirements down first
This is the highest-return habit in the entire interview, and most candidates skip it.
Split the board in two:
Functional - what the system does. "Users can upload a video. Other users can watch it. Users can search by title." Three to five bullets, no more.
Non-functional - the properties that constrain the design. Expected scale, latency targets, availability, consistency requirements, durability, read-heavy or write-heavy.
Writing them down lets the interviewer correct you early if you have misread the prompt, and gives you something to point back to when you justify a decision. Non-functional requirements are what actually drive architecture. "Strongly consistent" and "eventually consistent" produce completely different systems from the same functional spec.
Estimation without pretending to precision
Back-of-envelope maths is not about being right. It is about establishing an order of magnitude so you know whether you need one database or a sharded cluster.
Work through:
- QPS. Daily active users times actions per user, divided by 86,400 seconds. Then multiply by 2-3 for peak.
- Read/write ratio. A 100:1 read-heavy system justifies aggressive caching and read replicas. A write-heavy one does not.
- Storage growth. Average object size times writes per day times retention. Per day, per year.
State every assumption aloud: "I am going to assume 10 million daily actives and about 5 actions each, so roughly 500 million requests a day, call it 6,000 QPS average and 15,000 at peak." If the interviewer disagrees they will tell you, and adjusting cleanly is itself a positive signal.
The building blocks worth understanding
You need working knowledge of these, not memorised diagrams. For each one, know what problem it solves and what it costs you:
- Load balancing - L4 vs L7, health checks, sticky sessions and why they complicate scaling.
- Caching and invalidation - cache-aside vs write-through, TTL strategy, and the fact that invalidation is the hard part.
- SQL vs NoSQL - choose by access pattern. Multi-entity transactions and ad-hoc queries: relational. Known key and huge write volume: wide-column or document store.
- Sharding and partition keys - the partition key choice is the design. A bad one gives you hot shards and cross-shard queries.
- Replication and consistency - leader-follower, replication lag, what users see when they read their own writes.
- Queues and async processing - what you decouple, and the backpressure and ordering problems you inherit.
- CDN - static and media offload, cache headers, invalidation lag.
- Rate limiting - token bucket, where it sits, per-user vs per-IP.
- Idempotency - idempotency keys on writes, because retries are guaranteed at scale.
Talking about trade-offs
The phrasing that scores is simple: choice, reason, cost.
"I would put a Redis cache in front of the profile service because the read/write ratio is roughly 100:1. The cost is stale reads for up to the TTL, and a cold-start thundering herd if the cache drops. I would mitigate that with request coalescing."
Compare that to "I would add caching for performance." Same decision, half the score.
When you do not know something
You will hit a gap in the deep dive. The correct move is to say so and then reason.
"I have not implemented consensus directly, so I do not know Raft's internals. What I know is that I need a single leader per partition and a way to elect a new one without split-brain, which means a quorum. Let me reason from there."
Interviewers hire that. They do not hire confident bluffing, and they detect it in one follow-up question.
A 4-week plan while working full time
Week 1 - fundamentals. Two hours per topic across the building block list. Write a half-page for each: what it solves, what it costs, when not to use it.
Week 2 - read real systems. Engineering blogs from companies operating at scale. Focus on why they changed something, not what their final diagram looks like.
Week 3 - practice out loud. Four to six full 45-minute mock designs, timed, spoken, with a drawing tool open. Record yourself.
Week 4 - deep dives and gaps. Take the two components you fumbled most and go one level deeper. Do two mocks with a real person.
Use a whiteboard or shared drawing tool from day one. Diagramming while talking is a separate skill and it degrades badly if you have only ever done it in your head.
Common failure patterns
- Jumping straight to a diagram before anyone agreed on what the system does.
- Silent thinking. Thirty seconds of silence reads as being stuck. Narrate.
- Over-engineering for imaginary scale. Do not shard for 100 QPS.
- Ignoring the data model. Show the key entities and the primary access patterns. Many candidates never write a single table or key.
- No failure handling. What happens when this node dies, this queue backs up, this dependency is slow?
Variants: frontend, data, ML
The frame is the same, the components differ.
- Frontend system design centres on rendering strategy, state management, bundle and asset delivery, offline behaviour, API contract design and accessibility, not database sharding.
- Data engineering focuses on batch vs streaming, schema evolution, idempotent pipelines, late-arriving data, backfills and cost per query.
- ML system design adds feature stores, training/serving skew, model versioning and rollback, online vs offline evaluation, and latency budget for inference.
A note for senior candidates
At senior level the component knowledge is assumed. What separates the grades is scoping and prioritisation: deciding what to leave out, saying which part of the system carries the real risk, and choosing the deep dive yourself when the interviewer leaves it open. If you design everything evenly, you look like someone who has never had to ship under a deadline.
Key takeaways
- Write functional and non-functional requirements on the board before drawing anything. It is the single highest-scoring habit.
- Budget the 45 minutes explicitly and say the plan out loud.
- Estimate to an order of magnitude, state your assumptions, and never invent precision.
- Name the cost of every choice. A decision without a stated trade-off reads as luck.
- When you do not know something, say so and reason from first principles. Bluffing is caught immediately.