System Design Case Studies

Overview

This section contains 37 full interview-format system design case studies, and this page is the index into all of them. Each case study walks the six-step framework from requirements to follow-ups with explicit numbers, trade-off decisions, and deep dives — the way a strong candidate would drive a 45-minute design round. The pages complement real-world architectures, which analyze how actual companies built things; these pages optimize for practicing the design conversation itself.

Each case study follows the same structure so you can drill them like past papers:

1. Requirements & estimation — functional/non-functional, QPS, storage, bandwidth math
2. API + data model — concrete schemas, not hand-waving
3. High-level architecture — one diagram you should be able to redraw from memory
4. Deep dives — the two or three genuinely hard parts, with alternatives compared
5. Bottlenecks & follow-ups — where the design bends, what the interviewer asks next

The index below groups the case studies by domain so you can build coverage deliberately instead of reading them in alphabetical order. Two people who have drilled one case deeply from each group walk into an interview with a reusable answer for almost any prompt; someone who read thirty pages passively walks in with recognition but no recall. Use the study order at the bottom if you have limited time.

The case-study index

The table gives one line per case study: what makes it hard in one clause, and the concepts the page teaches that transfer to other designs. Domain groups collect problems that share a failure mode, so after a weak mock you can find the drill that targets the exact shape you missed. Names in the first column are the sub-flavor of the problem — use them to navigate, but expect interviewers to blend flavors freely.

Start here in each group

One page per group is the minimum viable coverage; these are the picks that teach the group’s signature constraint with the fewest prerequisites:

• Real-time & bidding → Ticketmaster — contention, holds, and payment idempotency in one design.
• Payments & fintech → Loyalty points — ledger thinking before the harder exactly-once problem in UPI.
• Marketplace & content → Food delivery — three-sided marketplace plus geo plus fan-out.
• Infra & platform → API gateway — the component-on-every-request budget discipline the group shares.
• Observability & orchestration → Task scheduler — leases, dedup, and fairness without storage-engine depth.
• Media & collaboration → Video transcoding — the pipeline/factory pattern the group is built on.
• Health & public sector → Vaccination slots — policy-driven eligibility and fairness under flash load.

How to pick a case study in an interview

You rarely choose the domain — the interviewer’s prompt does. The skill this index trains is mapping an unfamiliar prompt to the nearest drilled case in the first two minutes, then saying out loud which known design you are adapting. Interviewers score the mapping itself: “this is a Ticketmaster-shaped inventory problem, so I’ll start with no-oversell holds and a waiting room” is a strong opening sentence because it shows retrieval under pressure, not just preparation.

flowchart TD
    START["Interviewer prompt lands"] --> Q1{"Money, ledgers, payouts, or compliance in the prompt?"}
    Q1 -->|Yes| FIN["Drill: UPI, digital lending, loyalty points"]
    Q1 -->|No| Q2{"A hard clock: auction close, seat lock, ticket window?"}
    Q2 -->|Yes| RT["Drill: live auction, stock exchange, Ticketmaster"]
    Q2 -->|No| Q3{"One writer, millions of concurrent readers?"}
    Q3 -->|Yes| FAN["Drill: live comments, social graph, video conferencing"]
    Q3 -->|No| Q4{"A component other teams build on?"}
    Q4 -->|Yes| INFRA["Drill: API gateway, CDN, config service, secrets manager"]
    Q4 -->|No| Q5{"Heavy continuous ingest: logs, spans, metrics, video, photos?"}
    Q5 -->|Yes| DATA["Drill: metrics, tracing, log analytics, transcoding, Photos"]
    Q5 -->|No| APP["Drill: marketplace, dating, food delivery, exam platform"]

Two caveats keep this honest. First, most real prompts are hybrids — “design Zomato” is marketplace and dispatch and geo-indexing — so the flowchart picks your starting case study, not your whole answer; you bolt on the second drill where the first one runs out. Second, if nothing maps cleanly, fall back to the six-step framework and say so explicitly; interviewers reward a structured unknown far more than a misapplied memorized diagram.

Cross-cutting themes

Five distributed-systems motifs account for most of the deep-dive questions across all 37 case studies. Learn each theme once, in the case study that teaches it most starkly, and you will recognize it wearing different clothes everywhere else. The table maps each theme to its best-teaching cases; the paragraph after it explains why those pages are the right teachers.

Idempotency is best learned where retrying is most dangerous: UPI’s two-half money movement and Ticketmaster’s payment retry both turn “what happens if this runs twice?” from a footnote into the core of the design. The scheduler and durable-execution pages add the execution-side variant — dedup keys and event replay — so you can argue the exactly-once illusion from both the payment and the worker angles. Drill them in this order and the idempotency answer writes itself in any interview:

• UPI — idempotency keys across a debit-then-credit pair where a post-timeout retry must reconcile, never double-pay.
• Ticketmaster — payment idempotency for a 3-second double click, including the interaction between seat-hold expiry and retry windows.
• Distributed task scheduler — dedup keys that make at-least-once execution behave exactly-once to observers.
• Durable execution engine — activity idempotency and deterministic replay as the structural answer to “the worker died mid-step”.
• Loyalty points — an earn/burn ledger where a partner retry can never mint or burn points twice.

Hot partitions dominate flash-contention systems: a single auction item, a celebrity’s edges, or the Tatkal quota window concentrates load onto one shard while the rest of the fleet idles. The dating-app and fantasy-sports pages show the standard defenses (per-entity queuing, admission control, elastic inventory where the deadline is the hard constraint), and the stock-exchange page shows what changes when you cannot shed the load at all. The spectrum worth memorizing:

• Live auction — one item is the hottest key in the system; sharded rooms and single-writer ordering around it.
• Dating app — hot users skew per-user swipe queues; shed load at the deck level, not the request level.
• Social graph — celebrity edges make an otherwise random shard hot; replication and fanout plans differ per tier.
• IRCTC — the Tatkal window concentrates a day of load into five minutes; queue-based admission is the fix.
• Fantasy sports — a deadline write cliff with no peak-shifting option; elastic contest inventory absorbs it.
• Stock exchange — hot symbols cannot be shed at all; the design must route around them deterministically.

Fan-out economics is the shape of every “one writer, many watchers” system, and the cost model — per event, per recipient, per second — is the thing interviewers probe. TTL holds are its time-bound cousin: a reservation that must expire cleanly under failure, returning inventory to the pool without double-selling it in the interim. Both themes share one exam question: what happens to the pending item when the holder dies?

• Live comments — 100,000:1 broadcast where metering, sampling, and deliberate loss of low-value events are the design.
• Social graph — push vs pull vs hybrid feed assembly, with the celebrity boundary condition worked out.
• Live auction — outbid notifications to thousands of sockets in tens of milliseconds, per event.
• Fantasy sports — one ball-by-ball event re-ranks millions of contest entries.
• Ticketmaster — the 7-minute seat hold: expiry as a timer/scan problem with no-oversell guarantees.
• Telehealth and vaccination slots — calendar and slot holds released on confirmation or timeout.

Approximate counts close the loop with the probabilistic data structures — HyperLogLog, count-min, Bloom filters. The skill is judgment, not just machinery: knowing where an estimate is acceptable (long-tail ranks, frequency caps, live reaction counters) and where it silently corrupts money (settlement, billing, ledgers). Each teaching case below draws that line explicitly:

• Matchmaking & leaderboards — exact top-K, approximate rank-of-player for the 100M-player long tail.
• Ad tech — frequency capping and budget pacing under a 100 ms budget where exact counting is unaffordable.
• Dating app — a Bloom-filter pre-check before the Redis-set match lookup, sized against its false-positive rate.
• Metrics monitoring — the cardinality budget: what each extra label dimension costs in series count.
• Live comments — reaction and viewer counters as sampled, approximate aggregates nobody audits.

Coverage tracks

If you are preparing against a specific company profile, a track beats random sampling: pick the row matching the interview you expect, and treat the listed case studies as one connected course. Each track deliberately mixes one beginner-tier and one advanced-tier page so you practice transferring between comfort and discomfort zones. Tracks overlap intentionally — the fintech track shares two pages with the consumer track because payment shapes recur across both.

Study order recommendation

Order matters more than volume: every case study assumes machinery taught by earlier ones, and reading them out of order makes the deep dives feel arbitrary. The tiers below assume roughly 2–4 hours per case study if you do the estimation math yourself and redrew the architecture diagram from memory afterward. Move down a tier only when you can survive an unprompted 40-minute mock of any page above it.

If you have only one weekend, do Ticketmaster → UPI → live auction → metrics monitoring in that order: together they cover inventory contention, idempotent money, fan-out, and write-heavy storage — the four shapes interviewers reach for most often. Then read the HLD core topics page for any building block a deep dive referenced that you could not sketch unaided.

How to practice

• Read the case, then close it and sketch the architecture diagram from memory; compare against the page and note what you structurally missed rather than what you named differently.
• Do the estimation section with your own numbers first, then check where your order-of-magnitude slipped — capacity math errors are the most common silent score-killer.
• For every deep dive, articulate the rejected alternative and why out loud; that reasoning, not the final diagram, is what the interviewer scores.
• Drill one case from each domain group before adding a second from any group — breadth across failure modes beats depth in one favorite domain.
• After each mock, file the prompt under the cross-cutting themes table; the theme is the transferable unit, not the case study.
• Time the read: a first pass is 45–60 minutes, but a full pass — your own numbers, your own diagram, the deep-dive alternatives spoken aloud — is 2–4 hours, and only the second kind counts as a rep.
• Cross-check the primitives each case leans on: consistency patterns, backpressure, messaging systems, and the probabilistic data structures that show up in every counting-adjacent design.

Interview Questions

1. “Design a ticket-booking system for a stadium event” — which case study is the template and what changes? Ticketmaster is the base: no-oversell inventory, waiting-room admission, and idempotent payments. Changes come from the variant — standing vs reserved seating removes the seat map but keeps the hold model; free events remove payment idempotency but keep the herd; a lottery-based sale replaces contention with a randomization-and-notification pipeline. The skill being tested is saying which parts of the template survive and why.

2. “How would you design the ledger for a rewards program?” Start from Loyalty points: points are a liability, so the answer is a double-entry earn/burn ledger with expiry as a lapse event, not a cron job that decrements a column. Extend with banking ledger fundamentals if the interviewer pushes on auditability. The trap to avoid is designing a balance column with an UPDATE — say out loud why that fails under retry and audit.

3. “We need live scores pushed to 10 million concurrent viewers” — what does this decompose into? Live comments for the broadcast fan-out economics, plus fantasy sports if the scores drive per-user recomputation. The decomposition sentence matters: delivery plane (websocket/SSE edges), freshness plane (event ingest and sequencing), and personalization plane (what each user’s state must recompute). Interviewers score whether you separate those three before drawing boxes.

4. “Pick any system you know deeply and walk me through a failure mode.” This is where cross-cutting themes pay off: pick a drilled case, then pick its signature theme — hot partition for IRCTC, idempotency for UPI, fan-out collapse for live comments — and narrate the failure, detection, and mitigation. A rehearsed failure story with numbers beats a generic “we’d add monitoring” answer every time.

5. “Design a system that must never show stale prices but must also never go down” — which pages help? This is the consistency-vs-availability trade in disguise, so the base drills are distributed config service (serve-stale reads with bounded staleness) and feature flag service (kill switches as an escape hatch). The strong answer defines which reads can tolerate staleness and for how long, then puts the consensus machinery only under the writes that cannot. Both pages cost-quantify the trade instead of hand-waving it.

6. “How would you estimate the scale for a new product launch?” Estimation drills are embedded in every case study’s step 1, but the three most complete are ticketmaster (flash traffic math), google photos (storage and derived-artifact multipliers), and metrics monitoring (write-heavy cardinality math). The transferable habit is writing the assumptions down before the arithmetic, then sanity-checking the result against a known real system. Interviewers grade the assumptions, not the multiplication.

Key Takeaways

• 37 case studies, 7 domain groups, 5 cross-cutting themes: use the domain table to find a drill, the theme table to transfer it, and the tracks to sequence it.
• Every page follows the same five-part structure — drill them like past papers, not like articles to read.
• The first interview skill this index trains is mapping an unknown prompt to the nearest drilled case within two minutes.
• Beginner → intermediate → advanced ordering exists because deep dives assume machinery; skipping tiers makes reasoning feel arbitrary.
• One weekend minimum viable coverage: Ticketmaster, UPI, live auction, metrics monitoring — inventory, money, fan-out, storage.
• The theme, not the case study, is the transferable unit; file every mock prompt under a theme afterward.

Scope notes

These pages are interview drills, not production reference architectures, and treating them as either of the adjacent things weakens your prep. For how real systems were actually built, read the real-world architectures section; for the textbook primitives the deep dives assume, read the HLD core topics. The case studies compress real systems into one defensible 45-minute narrative — the simplifications are deliberate teaching choices, and the pages say so where the real systems diverged.

• They are not exhaustive: each page picks the two or three deep dives an interviewer would most likely probe, not every subsystem the product has.
• They are not vendor-neutral surveys: named products (Airflow, TAO, Gorilla) are cited as design evidence, not as deployment recommendations.
• They are not a substitute for speaking: the diagrams only become interview answers when you rehearse them out loud under a clock.

Cross-References

• Design Framework — the six-step method every case study applies
• Real-World Architectures — how actual companies built related systems, for the “has anyone done this?” follow-up
• HLD Core Topics — the building blocks the deep dives reference repeatedly
• Banking Ledger — the ledger primitive behind the payments, lending, and loyalty studies
• Backpressure — the load-shedding vocabulary used throughout the flash-contention studies
• Probabilistic Data Structures — the sketch toolkit behind the approximate-counting theme
• LLD: Machine Coding — the single-process class-design counterpart to these distributed designs