New to system design
Start here if you've shipped features but never designed a system from scratch in an interview. These six stops build the vocabulary and mental shape every senior engineer has internalised.
For: Junior → mid-level, first system design round coming up
After this path
Turn a vague prompt into a designable problem, sketch the right high-level shape, and defend the API contract.
- 1Skill
Requirements & scope framing
The first five minutes decide the next forty. Candidates who skip scoping design the wrong system brilliantly — and still fail. The ones who nail it look senior before they've drawn a single box.
Why this, here: Before anything else: how to turn a vague prompt into a designable problem in five minutes.
- 2Skill
Capacity estimation (back-of-envelope)
Every downstream decision — cache size, shard count, replica count — collapses onto one question: what are the numbers? Candidates who skip this are designing vibes, not systems.
Why this, here: Give every number in your design a defensible origin — not "a lot" or "millions".
Checkpoint
Before moving on: pick any consumer product you use daily and sketch its QPS, storage growth per year, and peak-hour bandwidth on a napkin in under three minutes. If you can’t, re-read — the rest of the path assumes this is muscle memory.
- 3Skill
High-level architecture
The HLD is the diagram every subsequent question is asked against. Clear boundaries + explicit dataflow beats clever components every time. Most candidates over-draw; seniors underdraw and label.
Why this, here: How to draw the shape of a system: boundaries, dataflow, sync vs async.
- 4Pattern
Read-heavy
Reads dominate writes by 10:1 or more. Every layer exists to keep the primary out of the hot path.
Why this, here: The shape 70% of prompts take. Recognise it in two minutes; design the right thing.
Checkpoint
Gut-check: name three interview prompts that are read-heavy in disguise and one that looks read-heavy but isn’t. If you can’t, the recognition isn’t sticky yet.
- 5Skill
Caching strategy
"We'll add a cache" is where weak designs die. Interviewers ask: which one, caching what exactly, with what TTL, invalidated how, behind which API boundary? If you can't answer all five, the cache line in your diagram is decoration.
Why this, here: The biggest lever in the read path. Know the four patterns and when each wins.
- 6Skill
API contract design
The API is the contract every client writes code against. Vague endpoints here metastasize into ambiguity everywhere else in the design. Interviewers use API design to separate candidates who have shipped from candidates who have read blog posts.
Why this, here: Every design ends with "walk me through the API". Be ready with idempotency + pagination + error shapes.