Four phases covering all 38 lessons at roughly 6–10 hours a week. Every week ends in a deliverable, because a completed reading list is not preparation and a working artefact is something you can talk about in a deep-dive round.
0 of 10 weeks complete
Tick a week when you have finished its deliverable, not just its reading.
The vocabulary, the arithmetic and the components everything else is built from.
Goal: Explain latency vs throughput, availability nines and what each standard component is for - without notes.
Deliverable: A one-page requirements document for a product of your choice, with numbers for every non-functional requirement.
Goal: Produce QPS, storage and bandwidth estimates for any prompt in under three minutes.
Deliverable: Capacity plans for three different products, each ending in a design decision the numbers forced.
Databases, caching, load balancing and the network layer, in depth.
Goal: Trace a request from URL to response with latency attached to every hop; design an idempotent, paginated API.
Deliverable: A complete API contract with idempotency keys, cursor pagination and a versioning policy.
Goal: Explain index mechanics, pick a database from access patterns, and name the anomalies each isolation level permits.
Deliverable: Reproduce a lost update and write skew against a real database, then fix each three ways.
Goal: Design a cache layer that survives stampede, penetration and avalanche; choose a balancing algorithm and defend it.
Deliverable: Add caching to a real endpoint and measure hit rate, p99 and origin QPS before and after.
Consistency, consensus, messaging and the patterns that hold services together.
Goal: Explain replication lag and read-your-writes; choose a shard key and defend it against all four tests.
Deliverable: Implement a consistent hash ring with virtual nodes and empirically verify the key-movement claims.
Goal: Explain Raft and why majorities prevent split brain; design a saga with compensations and an outbox.
Deliverable: Implement an order saga with idempotent compensations, crash-tested between every step.
Full case studies out loud, under time pressure, then interview polish.
Goal: Make a call chain survive a slow dependency; build a distributed rate limiter; instrument RED metrics.
Deliverable: A rate limiter enforcing a global quota across several nodes with no per-request coordination.
Goal: Deliver three full designs out loud, timed at 45 minutes each.
Deliverable: Three recorded 45-minute designs with photographed whiteboards and a self-assessment for each.
Goal: Handle the largest-scale prompts, then rehearse the framework until it is automatic.
Deliverable: Two mock interviews with another person, graded against the rubric, plus a written trade-off cheat sheet in your own words.
Attempt the design yourself before reading the lesson. You will remember the parts you got wrong far better than the parts you read passively - and the gap is exactly what to study.
A design you can write is not a design you can present. Set 45 minutes, talk to an empty room, and record it. The gap between your written and spoken answers is always large and always fixable.
Force yourself to estimate before drawing, every single time. The habit is what stops you over-engineering, and it is the single clearest senior signal available in the first ten minutes.
Deep knowledge of Postgres - indexes, isolation, replication, vacuum - transfers to every other store and lets you answer follow-ups two layers down. Breadth across ten databases you have never run does not.
Read public post-mortems. They teach failure modes no textbook covers, and 'this is how it failed at scale for someone else' is the most memorable thing you can say in an interview.
The candidate who says 'one Postgres instance handles this until 10,000 writes per second, and here is the number where it stops' beats the one who reaches for Kafka immediately. Restraint is a scoreable skill.