Chapter 3 · System Design Fundamentals
A Framework for System Design Interviews
Open-ended design questions only feel chaotic when you walk in without a plan. Here is a four-step routine that turns the next 45 minutes into a calm, guided conversation about trade-offs.
▶ Open the companion slidesHere is the thing to get straight first: the interviewer is judging how you think, not the drawing you end up with. No real system fits on a whiteboard in an hour, and everyone in the room knows it. What they are watching is how you reason when the question is vague, how you choose between options that are all flawed in some way, and how you work with another person while doing it.
Alex Xu, System Design Interview (Vol. 1), Chapter 3. Companion deck:
slides — jump to any slide with the
Slide N chips.
Go deeper: the System Design Primer's
"How
to approach a system design interview question" — the same spine, with practice
prompts and worked solutions.
What is actually measured Slide 2
Four things are being assessed in every question. The architecture you end up drawing matters far less than these.
1 · Can you frame the problem?
Can you take a vague question and turn it into a specific one, with clear assumptions and a target size written down?
2 · Do you know the parts?
Do you know which building blocks exist, what each one is good and bad at, and how they fit together?
3 · Can you name the cost?
When you choose something, can you say what you gave up to get it — speed, money, correctness, or extra work for whoever runs it?
4 · Can you work with someone?
Do you pick up on hints, change direction without sulking, and treat the interviewer as a colleague rather than a judge?
The four-step spine Slide 3
It doesn't matter whether the question is a chat app, a ride-hailing dispatcher, or a metrics pipeline — the same four steps work. Follow them on purpose and the interview stops feeling like something you're making up as you go. The timings below assume a 45-minute interview.
Do them in order — but go back to step 1 if a deep dive turns up a requirement you missed.
Step 1 — Understand & scope Slide 4
The most common way to fail is to carefully solve a problem nobody asked you to solve. Asking questions is not stalling — it is part of the design work. Say your assumptions out loud, and write the scope you agreed on in a corner of the board so you can both point at it later.
Functional — what must it do?
The 2–3 non-negotiable user flows; what's explicitly out of scope; and whether it's read- or write-heavy (that one answer flips the architecture).
Non-functional — how well?
Scale (DAU, peak QPS, payload), latency & availability targets (p99, SLO), consistency tolerance, and hard constraints (region, regulation, mobile-first).
Step 2 — High-level design Slide 5
Sketch the main components and how requests flow between them. Keep it deliberately shallow — skeleton, not finished product. Five or six boxes is plenty.
Step 3 — Deep dive Slide 6
This is where most of the signal is produced. The interviewer almost always nudges you — "let's talk about how the feed is generated" or "what if a worker dies mid-job?" Take the hint. Pick one or two components and unpack them.
What to unpack
Data layer (schema, partition key, hot keys); cache strategy (write-through vs aside, TTL, invalidation); async pipeline (at-least-once, idempotency, dead-letters); a specific algorithm; or failure modes.
How to dive without drowning
Quantify first ("50k writes/s, so one Postgres won't fit"); name 2–3 real options; pick one and state its cost; walk a read and a write through out loud; then stop — don't ramble past the answer.
If the interviewer steers you elsewhere, drop the current thread immediately and follow the new pointer. It's routing, not interruption.
Step 4 — Wrap up Slide 7
Spend the last minutes proving you can see your own design clearly.
Call out bottlenecks
Be specific: "the single-primary write path saturates near X QPS; the cold-start cache-miss storm is the other risk."
Sketch the next moves
Shard further, add a per-region read replica, batch writes through a buffer, introduce a CDN — framed as the next conversation, not promises.
Operate it
What do you log, what do you alert on, what's the SLI? Mention deploys, on-call, and a failure-recovery playbook.
Own the gap
"Given more time, I'd first revisit X — it's the tradeoff I'm least confident about." Owning uncertainty reads as senior.
The time budget Slide 8
Pacing is graded even if no one says so. The most common failure is spending 25 minutes on clarifications and never reaching a real design. A 45-minute slot, roughly:
For a 60-minute slot, scale each block — but keep the deep-dive share the largest.
Communicate — how you talk is the answer Slide 9
A silent ten minutes at the whiteboard is the most expensive ten minutes of the round — the interviewer can only score what they hear.
- Externalise the thinking. "I'm weighing two options — one relational store, or split reads and writes…" Say it before you draw.
- Confirm, don't assume. If a requirement could swing the design, ask.
- Narrate every tradeoff. "Low latency, but it adds an eventual-consistency window" — the single highest-signal habit.
- Steer with hypotheses. "My guess is the queue is the first bottleneck — let's check." Inviting verification is collaborative.
- Take the hint, gracefully. "What about X?" is routing, not curiosity. Accept the redirect without defending the old path.
- Recover openly. "Actually that index doesn't help — let me revise." Visible self-correction is a strength.
Red flags that sink strong candidates Slide 10
Jumping to a solution
Hearing "design Twitter" and drawing Kafka + Cassandra + CDN before asking how many users or which features. Pattern-matching isn't design.
Ignoring scale
A clean architecture that quietly assumes a single DB, single region, a few hundred users. They're waiting for the back-of-envelope math.
Verdicts without tradeoffs
"I'd use Cassandra." Why not DynamoDB? Why not sharded Postgres? A choice with no stated cost reads as cargo-culted.
Defensiveness under pushback
Treating questions as attacks. Rigidity here is read — accurately — as how you'll behave in real design reviews.
What "strong hire" looks like Slide 11
Rubrics vary by company, but the shape is consistent — and it's rarely about the "right" architecture.
| Tier | Behaviour the interviewer observes |
|---|---|
| Strong hire | Drives the conversation. Quantifies before designing. Proposes multiple options, picks one, names the cost. Catches their own mistakes. Lands a coherent design with a real deep dive and a clear next step. |
| Hire | Reaches a working design with light prompting. Knows the building blocks. Tradeoffs appear mostly when asked; the deep dive is competent but not unprompted. |
| Mixed | Needs steering through each step. Picks reasonable components but can't defend them. Misses scale or consistency until prompted. Deep dive stays superficial. |
| No hire | Skips clarification. Latches onto one technology. Can't explain why one choice beats another. Becomes defensive, or runs out of things to say. |
Active recall
Cover the answers. Say each one out loud before you tap to check.