Course roadmap
Pick a reading order for the four phases, see what each one is for, and jump to the section that fixes your weakest interview axis.
Four phases, roughly sixty lessons, ordered so that no lesson depends on a term you have not met yet. Phase 1 supplies the vocabulary, the mechanics of the interview hour, and the arithmetic. Phase 2 is the set of building blocks that appear in every design. Phase 3 is the material you reach for only when a design demands it, and Phase 4 works eight designs end to end. Read it in order the first time and use this page to jump back.
How the phases fit together
The dotted edges carry the weight. Phase 3 is not a prerequisite for Phase 4 — nothing in a URL shortener needs Raft, and reaching for consensus before you have scoped the problem is one of the recognisable ways to lose the round. And Phase 4 feeds backwards: each worked design ends at the component you could not defend, and that names the Phase 2 lesson to re-read. The loop is the study method, not a decoration on it.
Phase 1: Foundations
Goal: the vocabulary, the shape of the interview, and the arithmetic that turns opinions into decisions. Duration: 1–2 weeks. Do not rush it; every later phase assumes this one.
- Intro to System Design — what system design is, why it is worth doing deliberately, splitting functional from non-functional requirements, and the terminology the rest of the course assumes.
- Basic Components — clients, servers, databases, load balancers, caches and networks. One lesson each: what the box does, and what it costs you.
- The Interview Process — what the round actually tests, the four-step framework, how candidates lose, and how to say a trade-off out loud so it scores.
- Estimation — back-of-the-envelope arithmetic, the latency ladder, and Little's Law for sizing pools and explaining saturation.
Phase 2: Core concepts
Goal: deep familiarity with the components you will assemble in every design. Duration: 3–4 weeks. This is the longest phase and the one worth re-reading.
- Scalability — horizontal versus vertical scaling, load balancing in depth, and why stateless services are what make horizontal scaling cheap.
- Data Management — relational storage, NoSQL and when it earns its place, replication and sharding, caching strategies, and consistency, where CAP is the choice you make when a partition occurs and PACELC covers the rest of the time.
- Networking — DNS, TCP/IP, HTTP, REST, WebSockets, and a hop-by-hop walkthrough of one request from keystroke to response.
- Design Patterns — microservices, message queues, API gateways, proxies and CDNs, plus idempotency and the outbox pattern: at-least-once delivery produces duplicates, duplicates make idempotency mandatory, and a dual write to a database and a broker is where the duplicates come from.
- Availability & Reliability — redundancy, fault tolerance, monitoring, rate limiting, circuit breakers, and tail latency, because p99 is what users feel and the mean hides it.
Phase 3: Advanced topics
Goal: the concepts large-scale systems need, held in reserve until a design calls for them. Duration: 2–3 weeks.
- Distributed Concepts — concurrency, consensus (Paxos and Raft), and distributed locking.
- Security — authentication versus authorization, encryption in transit and at rest, and the common threats.
- Specific Technologies — cloud platforms and Kafka versus RabbitMQ.
- Big Data Processing — batch versus stream.
Phase 4: Worked designs
Goal: run the framework end to end, under time, on problems that are actually asked. Duration: ongoing, 2+ weeks.
Eight designs, each scoped, estimated, drawn, taken three levels deep on one component, then broken on purpose: a URL shortener, a rate limiter, a news feed, chat, a notification system, ride matching, image and video delivery, and search autocomplete. A closing practice lesson covers how to run a mock against yourself, what to record, and how to score your own transcript against the four axes from Phase 1.
The numbers that recur
Every phase uses the same constants, so a figure quoted in one lesson holds in the next.
| Constant | Value | What it decides |
|---|---|---|
| 1 million requests/day | ~12 QPS average | The everyday unit of traffic |
| Peak traffic | 2–5x average | What you provision for |
| Commodity Postgres box | ~5,000 simple QPS | Whether to shard |
| Datacenter round trip | 0.5 ms | Cost of one extra service hop |
| Memory reference / SSD read | 100 ns / 100 µs | Why a cache hit beats a miss |
| India to US East round trip | ~200 ms | Why the CDN sits near the user |
The arithmetic that opens every design in Phase 4 is this one:
1,000,000 DAU x 20 requests/day = 20,000,000 requests/day
20,000,000 / 86,400 s ~= 230 QPS average
230 x 4 (peak factor) ~= 1,000 QPS peak
1,000 QPS peak against a box that handles roughly 5,000 answers "do we shard?" with "not yet", and names the number that would change the answer. That is the move the whole course is arranged to produce.
In an interview
Nobody asks you to recite a roadmap. What carries into the room is the order, because problem navigation is scored before technical depth: scope, estimate, design, then go deep on one component. An interviewer who watches you jump straight to a component has already marked the first axis down, whatever you draw next.
Say the order out loud and the interviewer can follow you: "Before I draw anything, I want the features in scope and a rough scale — then I will size it, sketch the high-level path, and pick one component to go deep on."
The mistake that loses points is opening in Phase 3. Consensus protocols, vector clocks and CRDTs signal reading rather than judgment when they arrive before a single requirement is fixed, and they invite a follow-up you cannot answer. The second mistake is breadth: naming eight components and defending none of them at level three. One deep component beats eight shallow ones on every rubric this course is built against.
Check yourself
You have three weeks before an onsite, you can already name every component in Phase 2, but you have never written a QPS figure in an interview. What do you read, and what do you skip?
Phase 1's Interview Process and Estimation sections first — that is under an hour of reading and it fixes the two axes you are failing. Then go straight to Phase 4 and work designs under a timer. Skip Phase 3 entirely until a design you are working forces it; consensus and encryption are not what is costing you the round.
A prompt gives you 5 million daily active users each loading a feed 10 times a day. Do you shard the database, and what would change your answer?
5M x 10 = 50M requests/day; 50M / 86,400 s is about 580 QPS average, and at a 4x peak factor about 2,300 QPS. That is under the ~5,000 QPS a single commodity box handles, so no shard yet — put a cache in front and keep one primary with a read replica. The answer changes if writes rather than reads dominate, if traffic grows past roughly 2x, or if a single query fans out into several.
Halfway through Phase 4 you can draw a news feed but freeze when asked what breaks first at 10x traffic. Which phase do you go back to, and why not the one that feels harder?
Back to Phase 2, not Phase 3. "What breaks first" is a question about caches, connection pools, replication lag and the tail — all Phase 2 material — and the honest answer usually names a component and a number, not an algorithm. Phase 3 feels harder because it is unfamiliar, which is a different problem from being the thing that is losing you points.