Skip to content
Knowledge Hub

Case Studies Basic

Articles in the other sections isolate one mechanism each: indexes, transactions, caching, redirects, idempotency. A case study works the other way: take a concrete product, estimate the load from explicitly stated assumptions, then see where the mechanisms collide.

Learning path

Section titled “Learning path”
Article What you learn Related mechanisms
Designing a URL shortener Derive QPS and storage from assumptions, code length from base62, pick a code allocation scheme and a 301/302/307/308 redirect status B-tree index, cache-aside, SSRF
Designing a news feed Fan-out on write vs read, the celebrity problem and the hybrid threshold, cursor pagination, invalidation on delete and unfollow Redis data structures, keyset pagination, outbox
Designing a payment system Payment state machine, idempotency keys toward the gateway, unknown outcome after a timeout, double-entry ledger, reconciliation Idempotency-Key, outbox, data type pitfalls

How to read a case study

Section titled “How to read a case study”
  1. Read the assumptions table first. Every number after it is derived from there.
  2. Recompute one number with your own assumptions and compare it with the article.
  3. Look for decisions that constrain each other: choosing 301 makes the target hard to change; a long cache TTL slows down revocation; sequential codes are short but guessable.

There is no universally correct architecture, only an architecture that fits the stated requirements.

Read alongside

Section titled “Read alongside”