Revision · Case Studies — Designing Real Systems

This part put the vocabulary from earlier parts to work through fourteen “design X” walkthroughs, all built on one repeatable skeleton so the method outlasts any single answer.

What this part covered

• The six-move framework — clarify, estimate, sketch the API, model the data, draw the architecture, then deep-dive the bottleneck; walking them in order buys a defensible design instead of a defended diagram.
• Requirements and the read:write ratio — non-functional requirements do most of the design work, and the read:write ratio is the first number to pin because it steers you toward caches-and-replicas or queues-and-partitioned-writes.
• Read-heavy KV stores (URL shortener) — unique short-code generation (counter+base62 vs hashing) plus caching the hot read path is the archetype for a 100:1 read-heavy service.
• Fan-out systems (news feed, notifications, typeahead) — fan-out-on-write vs on-read, with the celebrity problem forcing a hybrid, is the recurring tension across feeds, multi-channel notifications, and prefix-search autocomplete.
• Stateful real-time delivery (chat) — WebSockets for a persistent connection, message ordering, and holding stateful connections is the archetype for sub-200ms delivery that must never silently drop.
• Correctness under money and concurrency (payments, Google Docs) — idempotency keys stop double charges and a ledger keeps money balanced; OT and CRDTs make concurrent edits converge instead of clobbering each other.
• Geospatial and firehose scale (Uber) — indexing a moving map with geohash/quadtree/H3 and absorbing the location firehose is the dispatch archetype.
• Bandwidth- and index-bound systems (YouTube, search engine, web crawler, Dropbox) — transcoding pipelines with CDN egress, inverted indexes with BM25 scatter-gather, polite frontier queues, and content-addressed chunking each scale a different bottleneck.
• Determinism at the extreme (stock exchange) — single-threaded matching for reproducible order-book results, then sequencing and durability for HA, trades throughput headroom for correctness you can replay.

The takeaway

Every case study is the same problem wearing a different hat: estimation buys you the right to choose, the API buys a contract, the data model buys predictable access, and the deep dive is where you pay — in consistency, money, or complexity — for the scale you asked for. Master the six moves and any prompt becomes tractable. Next, Part 10 turns to the rare failure modes that these designs quietly assume away.