How much System Design do you already have?
Be honest — nobody is watching. This only decides which chapters come first; every chapter stays open to you either way.
“I can reason about a simple system.”
Start with the client-server model and the handful of building blocks — load balancers, databases, caches, APIs — that every design question reuses.
- You can build an app, but haven't been asked to design one at scale
- "System design interview" sounds intimidating and vague right now
- You want the building blocks once, in order, before the tradeoffs
“I can design for real traffic.”
You know the building blocks. Now learn how they behave under real load: load balancing algorithms, CDNs, queues, and consistency tradeoffs.
- Comfortable with the client/server/cache/database building blocks
- You've heard "eventual consistency" and nodded without being sure
- You want a medium-sized design (a feed, a chat app) to feel tractable
“I can defend a design under pressure.”
The CAP theorem in depth, sharding at scale, distributed consensus, and the capacity math behind designing something like Twitter or Uber.
- You can already design a medium-sized system with tradeoffs
- You want to defend a design against "what if this fails" follow-ups
- You want the why under consensus, sharding and capacity estimation
Not sure? Start at Beginner — every path opens at the section people usually skip.
Full syllabus
Everything each level eventually covers — ticked sections are written, the rest are still on the desk.
Beginner7 / 7 sections written
There is no answer key — the interviewer is scoring how you got there, not where you landed.
A senior candidate can narrate everything between the keypress and the pixel — and knows what each hop costs in milliseconds.
Buy a bigger box or buy more boxes — and one modern box is far bigger than the candidate who instantly reaches for a cluster believes.
The choice is decided by access pattern and consistency need — "SQL doesn't scale" is a claim that will cost you the interview.
A cache is one bet placed at seven distances — and the interesting number is never the hit rate, it's the miss rate.
The API is the coupling surface — every round trip, every version and every retry is a design decision someone will live with for years.
The full 45-minute arc on the classic warm-up question — where every number is shown, every choice is defended, and the trap is the click counter.
✅ Checkpoint: you can walk through designing something like a URL shortener end to end — client, API, database, cache — and explain each choice.
Intermediate9 / 9 sections written
The box everyone draws and nobody explains — where L7 earns its latency, why consistent hashing keeps recurring, and how a health check turns a brownout into an outage.
Move the bytes closer to the user — the cheapest 10x in system design, right up to the moment you cache something personal.
The request path should only do the work the user is actually waiting for — everything else goes on a queue and gets retried.
Every consistency model is just a rule about which stale reads you are willing to let a user see.
The only thing standing between one badly-behaved client and everybody else's latency.
Availability multiplies down your dependency chain — five nines in one box is four nines in a system.
Block, file, object — and why the bytes of a user upload should never touch your app servers.
The database scans; the inverted index looks up. Everything else in search is ranking and staleness.
Fan-out on write, fan-out on read, and the hybrid that exists because one account has 150 million followers.
✅ Checkpoint: you can design a medium-sized system (a news feed or chat app) with load balancing, caching, queues and a stated consistency model.
Advanced8 / 8 sections written
You never "pick two" — you pick one letter during a partition, and PACELC tells you what you picked for the other 99.9% of the time.
One machine is a limit, not a bug — but the shard key you pick in week one is the decision you will still be paying for in year five.
Getting a group of unreliable machines to agree on one value — and why your job is to use a consensus system correctly, not to write one.
At scale something is always broken — the design question is never "will it fail" but "what happens to everything else when it does".
Metrics say something is wrong, traces say where, logs say what — and p99 says whether anyone noticed.
The whiteboard arithmetic that turns hand-waving into a design — no calculator, under two minutes, out loud.
Six systems you use every week, one interesting decision each, and the bill that came with it.
Nobody is grading your architecture. They are grading whether you knew what you were giving up, and said so.
✅ Checkpoint: you can run a full system design interview conversation for a large-scale system, with back-of-envelope numbers and a defensible failure story.
- This curriculum leans on the other topics on this shelf on purpose — the databases chapter here assumes you already have SQL & Databases, the queues chapter assumes Node's message-queues chapter. System design is where they combine.
- Every level ends in a walkthrough (URL shortener → news feed → real case studies) because tradeoff thinking is a conversation skill, not a fact you memorize.
- Distributed consensus and chaos engineering are the deepest, rarest layer — most system design interviews never go there, but the advanced tier doesn't skip it.