Complete guide · 27 topics · interview-ready
System design, from requirements to a whiteboard you can defend
Every topic here answers three questions: why does this exist, what does it cost you, and what do you say when an interviewer asks. No architecture diagrams to memorise — just the reasoning that produces them.
How to use this
Three steps, one topic a day. The order below is deliberate: each block assumes the one before it.
- Pick one topic and understand why it exists. Every component in a distributed system is a fix for a specific failure of the simpler design. Learn the failure first — the component then becomes obvious rather than something to memorise.
- Design one related system on paper and say every decision out loud.
Not typed. Spoken. The gap between "I understand sharding" and "I can explain
why I sharded on
user_idand what breaks when one user goes viral" is the entire interview. - Do not memorise architectures. Practise connecting a requirement to a component. "10M writes/day, read-heavy, eventual consistency is fine" should produce a design; a memorised Twitter diagram will not survive the first follow-up question.
After every design decision, say the sentence "…and the cost of that is ___." A design with no stated costs reads as a design you do not understand. Interviewers are grading the tradeoff, not the box.
The 27 topics
Block A — Fundamentals
The four things every single design touches, in the order you use them.
Block B — Data
Where the hard, irreversible decisions live.
Block C — Distributed behaviour
How independent machines cooperate without lying to each other.
Block D — Platform
The systems you plug in rather than build.
Block E — Full designs
Seven complete walk-throughs. Read these last; they only make sense once A–D are in place.
The interview section is separate on purpose: a 45-minute framework, phrases that buy thinking time, a 60-question bank with full answers, the grading rubric interviewers actually use, and the red flags that sink otherwise-good candidates.
The 27-day plan
One topic a day. Tick a day when you have both read it and explained a related design out loud. Progress is stored in this browser only.
The method, in one diagram
Every design in this guide follows the same path. When you freeze in an interview, restart from box one.
Numbers worth memorising
You need these fast enough to do arithmetic while talking. Full versions on the cheat sheet.
The mistakes that cost offers
- Drawing boxes before agreeing on requirements.
- Never stating a single tradeoff.
- Naming technologies as answers — "I'd use Kafka" with no why.
- Ignoring the interviewer's hints. They are steering you on purpose.
- Silent thinking for 60+ seconds.
- Designing for a billion users when the prompt said a million.
- Forgetting the write path — most candidates over-plan reads.
- No failure discussion: what happens when this box dies?
- Sharding on a key you cannot query by.
- Claiming "exactly-once delivery" without qualification.
"Reads are 100× writes, so I'll optimise the read path with a cache and accept a stale window of a few seconds. That's fine for a feed and not fine for a balance — if this were money I'd read from the primary instead."