Six basics modules start from zero (what a server, an API and a database are), then twenty-nine modules take you from "what happens when I open a web page?" to replication, sharding, consensus, workflows, reliability and AI systems. Then 46 worked designs put it all together: URL shorteners, chat, news feeds, ride hailing, payments, video and more. Every idea is explained plainly, shown moving step by step, and tried in an interactive widget.
Knowing the building blocks is half the job; the other half is delivering a working design in 45–90 minutes while someone watches. This track uses one framework everywhere: nine phases, always in the same order. Learn it once, and every worked design, every practice run and every real interview follows the same path.
You always know what comes next, you put a complete simple design on the board by the halfway mark, and your deep dives are chosen by your own measured targets, not by luck.
Phases 1–6 take about a third of the time. The remaining time goes to building the first working version and then making it hold up, which is where seniority shows. Phase 9 shows your judgement.
Learn Levels 1–3, then read one long-form design a week actively (attempt each section before reading it), do a timed run on paper every few days, answer the follow-up questions out loud, and use the review deck daily.
Read the full framework: what to do, write and say in each phase →
Every module has the same ten sections, so you always know where to look:
An everyday analogy and a plain explanation, a diagram and step-through player of the mechanism, then an interactive widget to try it yourself.
The trade-offs: when to use it, when not to, and what it costs. Then where it shows up in real systems and the technologies that implement it.
A memory hook with a full explanation, common mistakes, a design exercise to do on paper, a quiz, and the best free resources to go deeper.
The worked designs follow the interview framework, explained in Module 05. All 46 designs follow it phase by phase: clarifying questions, targets, numbers, the contract, a first version built one request at a time, deep dives that compare a bad, a good and a great answer, follow-up questions and a time plan.
Each design lists the modules it leans on. Do a design after you've finished those modules, and try it on paper before you read the answer.
The classic patterns, each taught inside the module where it's used. Follow a link to its explanation, scene and interview red flags.
| Area | Pattern | The problem it solves | Where |
|---|---|---|---|
| Data placement | Consistent hashing and virtual nodes | Which node owns a key, moving little data when nodes change | Module 15 |
| Data placement | Key salting (sharded counters) | One hot key overloading one shard | Module 15 |
| Replication | Leader-follower replication | Copies for reads and failover | Module 14 |
| Replication | Quorums (W + R > N) | Reads that see the latest write without a leader | Module 14 |
| Replication | Hinted handoff | Writes for a node that's briefly down | Module 13 |
| Replication | Read repair and Merkle trees | Replicas that missed writes catching up cheaply | Module 14 |
| Replication | Gossip | Cluster membership without a central registry | Module 14 |
| Storage | Write-ahead log | Durability: commit before the data pages reach disk | Module 11 |
| Storage | LSM tree and Bloom filters | Fast writes; skipping files that can't hold a key | Module 12 |
| Storage | Segmented log and high-water mark | Cheap retention; readers see only replicated data | Module 18 |
| Failure handling | Failure models | Saying which failures the design tolerates | Module 21 |
| Failure handling | Heartbeats and phi accrual | Deciding a node is down | Module 21 |
| Failure handling | Leases and fencing tokens | A paused ex-leader writing after losing its lock (split brain) | Module 21 |
| Failure handling | The Two Generals problem | Why a sender can never be sure its last message arrived | Module 21 |
| Coordination | Leader election (etcd, ZooKeeper) | Exactly one active coordinator | Module 21 |
| Coordination | Consensus (Raft, Paxos) | Agreement on a log despite crashes | Module 21 |
| Time and order | Lamport, vector and hybrid clocks | Ordering events without trusting wall clocks | Module 20 |
| Time and order | Unique IDs (Snowflake, ULID) | Sortable IDs generated on many machines | Module 20 |
| Consistency | CRDTs and conflict resolution | Concurrent writes that must merge | Module 16 |
| Consistency | Optimistic concurrency | Lost updates without holding locks | Module 17 |
| Consistency | Session guarantees (session tokens) | Users seeing their own writes, in order, on lagging replicas | Module 16 |
| Transactions | Two- and three-phase commit | Atomic commit across databases (and why it's avoided) | Module 15 |
| Transactions | Sagas and durable execution | Multi-step processes across services | Module 22 |
| Transactions | Transactional outbox and CDC | Updating a database and publishing an event together | Module 22 |
| Transactions | Idempotency keys | Retries that don't repeat side effects | Module 07 |
| Overload | Retries with backoff and jitter | Transient failures without retry storms | Module 24 |
| Overload | Circuit breakers and bulkheads | Stopping one failure from spreading | Module 24 |
| Overload | Token and leaky buckets | Rate limiting | Module 24 |
| Overload | Back-pressure and load shedding | Staying up when demand exceeds capacity | Module 24 |
| Data flow | Hierarchical aggregation | Millions of events into one update a second | Module 18 |
| Architecture | Event sourcing | State as an append-only history you can audit and replay | Module 28 |
| Architecture | CQRS | Separate write and read models, kept in step by events | Module 28 |
About 45 minutes a day, five days a week, using the routine on the Start here page: read on Monday, redo the widget and exercise on Tuesday, draw a design from memory on Wednesday, read one real engineering write-up on Thursday, and explain the week's idea out loud on Friday.
| Week | Study | Output by Friday |
|---|