Case Studies

SYSTEM DESIGN SERIES  ·  TOPIC 23 OF 23+  ·  the whole series, assembled
1. The Whole Course, as One Request
Every box below is a topic number. Watch one request visit almost all of them (looping)
In: a rate limiter (18) and a CDN (08) filter and absorb traffic before it's even "your" problem
Routing: a load balancer (06) hands the request to one of many stateless app servers (05)
Fast path: a cache hit (07) answers without ever touching the database
Slow path: a miss reaches a sharded (14, 15), replicated (11) database, indexed (10) for the read
Aside: the same request quietly drops a job on a queue (16) for a worker to finish later
Always on: observability (21) is watching the whole trip, the entire time
2. Case Study - URL Shortener
Wildly read-heavy, trivially simple to state
  • Encode an auto-incrementing ID as base62, or hash the URL and check for collisions
  • One row per short code, looked up by an index on that code (topic 10)
  • Reads outnumber writes by orders of magnitude - cache aggressively (topic 07), lean on read replicas (topic 11)
  • Rate limit the creation endpoint specifically (topic 18) - that's the one worth abusing
  • At real scale: shard the mapping table by code hash (topic 14) once one database can't hold it
3. Case Study - Chat / Messaging
Real-time, ordered, and it has to work while you're offline
  • A live connection is stateful (topic 05) - pinned to whichever server is holding it open
  • Offline? The message waits in a queue (topic 16) until you reconnect
  • A flaky connection means retried sends - idempotency (topic 17) keeps that from duplicating
  • Shard conversations by conversation ID (topics 14, 15) so one thread's messages stay together and ordered
  • Old history can be eventually consistent (topic 12) - the live message in front of you can't be
4. Case Study - News Feed
Personalized, at massive read scale - and a new trade-off appears
  • Fan-out-on-write: precompute every follower's feed the instant someone posts - reads are instant, but a celebrity's post means millions of writes at once
  • Fan-out-on-read: build the feed at read time by merging who you follow - writes are cheap, reads get slower the more you follow
  • Most real feeds do both, deliberately - fan-out-on-write for regular accounts, fan-out-on-read for the celebrities (topic 14's hot-shard problem, solved by routing around it)
  • The feed itself is just another cache (topic 07), refreshed by queued background work (topic 16)
5. Case Study - Distributed Key-Value Store
Almost every back-half topic, in one system
  • Consistent hashing (topic 15) spreads keys across nodes - adding one doesn't reshuffle everything
  • Every key is replicated to several nodes (topic 11); reads and writes agree via quorum (topic 19)
  • Consistency is chosen per operation (topic 12) - strong for a balance, eventual for a view count
  • Rebalancing or changing a leader safely still needs consensus underneath (topic 19)
  • Any exclusive maintenance step needs a properly fenced lock (topic 20) - not just a lock
6. The Interview Method
Not a formula - but a reliable order to think in
Clarify & Scope
Estimate the Scale
High-Level Design
Deep Dive
Name the Trade-offs
Every one of the 22 topics is an answer waiting for step 4
Nobody expects the "right" architecture from memory. They're watching whether you know which trade-off you just made, and why.
7. The Full Toolkit
Storage & Data:
✔ Caching (07), CDN (08)
✔ Indexing (10), Replication (11)
✔ Sharding (14), Consistent Hashing (15)
✔ Consistency Models (12), Transactions (13)
Every Real System Is Just These Trade-offs, Combined Deliberately
Traffic & Safety:
✔ Load Balancing (06), Queues (16)
✔ Idempotency (17), Rate Limiting (18)
✔ Consensus (19), Distributed Locks (20)
✔ Observability (21), Deploys (22)
🏁 23 topics, one toolkit. The best designs aren't the cleverest ones - they're the ones where every trade-off was made on purpose.