The problem atlas: classic designs decomposed
The canonical problems, each reduced to the stages that make it hard — the map from prompt to chapter.
The worked chapter taught the method on one problem. This closing chapter is the map: the canonical design prompts, each reduced to the two or three chapters that make it hard. Use it in both directions — given a problem, find its chapters; given a chapter, know which problems rehearse it. The core skill of the professional (and the interview) is exactly this classification, done fast and out loud.
The atlas
| Problem | The crux | Built from |
|---|---|---|
| News feed | fan-out on write (precompute feeds; celebrities explode it) vs on read (compute at request; hot users pay) — the hybrid: push for most, pull for the famous | reads, sharding, streams, derived |
| Chat | per-conversation ordering (one partition per conversation — DS ordering, applied), presence, delivery receipts as idempotent state machines | realtime, streams, jobs |
| Ride matching | geo index for candidates, then contention: two riders, one driver — a lock/reservation with expiry decides; surge is backpressure with a price tag | geo, writes, jobs, failure |
| Ticketing / flash sale | inventory is the invariant: reserve-with-TTL, confirm on payment, release on expiry; a queue at the door sheds the stampede honestly | writes, jobs, ratelimit, failure |
| Web crawler | the frontier is a giant priority queue; politeness = per-domain rate limits; seen-URLs = a Bloom filter at billions; DNS becomes your bottleneck | jobs, sketches, ratelimit, cdn |
| Video platform | upload → transcode fan-out → CDN economics; view counts at scale are sketches, not counters | blob, jobs, cdn, sketches |
| Notification system | multi-channel fan-out with per-user preferences, collapsing (“5 new likes”), per-channel rate limits, and idempotent sends — the duplicate notification is the brand-killer | jobs, streams, ratelimit, ids |
| Distributed counter / analytics | exact counters contend (shard them, sum on read) — or admit the question is operational and reach for HLL/count-min | sketches, sharding, derived |
Reading the table like a professional
Notice what repeats. Jobs and streams appear almost everywhere — because nearly every hard problem decomposes into “acknowledge fast, process async, keep order where it matters”. The invariant names the design: feed = eventual and cheap, ticketing = strict and reserved; ask “what must never be wrong?” and half the architecture writes itself. And hybrids beat purities: push+pull feeds, exact-then-approximate counters, homed-writes-active-reads regions — the canonical answers are almost all “both, partitioned by the case that stresses each”.
To turn the atlas into skill: take one row per week, run it through the worked chapter’s framework — requirements, envelope arithmetic, the boring design, deep dives where your numbers say it breaks — then read a real engineering-blog writeup of the same system (the aggregated reading list next door at /tech-blogs exists for exactly this) and diff their scars against your sketch. The gap is your syllabus, personalised. Do that eight times and you will have finished this course in the only sense that matters.