Stage 5
Case studies & interview craft
Worked designs — chat, feed, dispatch, ledger — with the interview framework.
- The system-design interview framework
A system-design interview isn't a test of whether you've memorized an architecture — it's a test of whether you can drive a vague prompt to a defensible design out loud, making trade-offs on purpose. This lesson is the framework the rest of this stage uses: scope the requirements, do the back-of-envelope math that sizes the problem, sketch a high-level design, then spend most of your time in deep-dives on the parts that actually matter, and close by naming the bottlenecks. It's less about any one system and more about the method — how to spend 45 minutes so the interviewer sees you think.
13 min - Design a URL shortener
The classic warm-up prompt, and a perfect one because it looks trivial and hides real decisions. Worked through the framework: it's a massively read-heavy key-value lookup, which points straight at caching and replicas; the only genuinely interesting question is how you generate short unique codes at scale without collisions, and whether the redirect is a 301 or a 302. This case study applies the interview method end to end and maps each decision back to the lesson that explains it.
12 min - Design a news feed
A follow-based feed (Twitter/Instagram home timeline) is the canonical fan-out problem, and it comes down to one decision with a famous exception: do you precompute each user's feed when someone posts (fan-out on write, fast reads, explosive celebrity writes) or assemble it when they open the app (fan-out on read, cheap writes, expensive reads)? This case study works the prompt through the framework, lands on the hybrid that every real feed uses, and shows why a celebrity with fifty million followers is the whole reason the naive answer breaks.
13 min - Design a chat system
A real-time chat (WhatsApp/Slack/Messenger) is the prompt that forces every hard part of stateful connections at once: millions of long-lived WebSockets, routing a message to a recipient connected to a different server, delivering reliably over networks that drop, and keeping order within a conversation. This case study works it through the framework and lands on the same spine Fable's chat actually ships — persist the message first, deliver over the socket second, and reconcile against durable history on reconnect — because the socket is delivery and the database is truth.
13 min - Design a ride-hailing dispatch system
Uber/Lyft dispatch is the prompt that forces the one thing no other case study does: geospatial data at scale. Millions of drivers each pushing a location update every few seconds is a brutal write load, and 'find nearby drivers' is a query no plain B-tree index can answer. This case study works it through the framework, lands on the geospatial-index answer (geohash / quadtree / S2 cells that turn 'near me' into a prefix or cell lookup), and separates the high-write location-ingest path from the matching path — the write/read split that defines the design.
14 min - Design a payment ledger
The capstone prompt, and the one where 'eventually consistent, cache it, fan it out' is exactly wrong — a ledger must be correct to the last unit, forever, under retries and concurrency. This case study assembles the answer from the whole curriculum: money as integers never floats, balances as a projection over an append-only log never stored as state, idempotency keys so a retried transfer applies once, and the strong-consistency single-writer concurrency control that a feed would never need. It's also, not coincidentally, exactly what Fable is — so this is the Fable case study delivered as an interview answer.
14 min