Foundational cases: write a full design doc
Hands-on project: pick one of the four foundational cases and produce a complete design document — requirements, back-of-envelope estimate, high-level architecture diagram, two deep-dive components, and a bottlenecks-and-tradeoffs section a senior engineer would sign off.
Reading four worked case studies is not the same as producing one yourself under the constraints a real review imposes. Pick one of the four systems, write the full design document end to end — the requirements, the estimate that picks the shape, the architecture, two hard components, and the failure modes — and defend every threshold with a number a staff engineer could check.
This project makes the unit operational: you run the full design loop for one system, justify each decision with the arithmetic from the cases, and surface the tradeoffs that separate a design that works from one that survives. The deliverable is a document, not code — the skill is reasoning, not typing.
Produce a complete senior-level design document for ONE of the four foundational systems (distributed key-value store, URL shortener, web crawler, or distributed message queue), following the same structure the cases used: requirements → estimation → high-level design → deep dive → bottlenecks and tradeoffs. Every numeric threshold in the doc must be justified by a back-of-envelope calculation, and every component choice by an explicit trade.
- A design doc with all five sections (requirements, estimation, HLD with a diagram, two deep dives, bottlenecks) readable in about ten minutes by another engineer.
- Every numeric threshold is backed by a shown calculation (no bare numbers), and the doc explicitly names which resource breaks first.
- Each of the two deep-dive components states the mechanism AND the alternative rejected, with the reason — not just a description of the chosen design.
- The bottlenecks section names at least four real failure modes specific to the chosen system, each with a mitigation, not generic 'add more servers' answers.
- A reviewer could disagree with a choice and see exactly which assumption to change — every decision is traceable to a stated requirement or number.
- Write the doc for a SECOND system and extract the shared skeleton: which moves (partition, replicate, dedup, cache, order) recur, and what changes the shape between the two.
- Add a 10x-growth section: recompute the estimate at 10x load and identify the first threshold you cross (a new shard, a cache tier, more partitions) and what in the design must change.
- Add an explicit consistency/availability stance: state where your system sits on CAP/PACELC and walk through exactly what a network partition does to reads and writes.
- Critique one of the four worked cases: find a requirement it under-served or a tradeoff it glossed, and propose the change with the number that justifies it.
- 01What are the five sections of a design doc, and what does each contribute?
- 02Why justify every threshold with a number and name the rejected alternative?
- 03What does the 'forcing requirement' do, and why find it first?
This project turns the four case studies into a repeatable workflow you can apply to any “design X” prompt. Pick one system and write the five-section design doc: requirements (and the single non-functional requirement that forces the rest — always-writable, read-heavy, never-overload-a-host, or durable-firehose); an estimate that derives QPS, storage, and a memory/bandwidth figure to one significant figure and names which resource breaks first; a high-level design with a diagram and a request walkthrough; two deep dives that each give the mechanism and the alternative you rejected with the reason; and a bottlenecks-and-tradeoffs section naming at least four real failure modes with mitigations. Justify every threshold with a shown calculation so a reviewer can disagree by changing an assumption, and record the trade behind every choice. An engineer who has written one of these end to end stops treating system design as a memorised diagram and starts treating it as reasoning with numbers — which is exactly what the whole track is teaching.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.