Overview

It is 10:00 and BoxOffice opens the sale of a stadium show: two million fans, sixty thousand seats. Over the semester you built every piece needed to survive that morning — a CDN and a WAF at the edge, stateless services behind a load balancer, a cache, a database that never sells a seat twice, a queue, a payment integration, observability, a load test that found the knee. This class puts the pieces together the way an interviewer asks for them: a one-sentence prompt, a blank whiteboard and 45 minutes.

The twelve case studies below are the classic system-design interview problems. They are not twelve unrelated systems: they are the same few ideas — cache the hot reads, take slow work off the critical path, choose a partition key, make retries safe, protect the one resource that cannot scale — combined in different proportions. Studying them is how the vocabulary of the course becomes a reflex.

Roadmap

1. This overview — how to study a case, how to use the playground, the cases at a glance and the patterns that repeat.
2. URL shortener — ID generation, base62, caching hot links, analytics off the critical path.
3. Rate limiter — token bucket and sliding windows, atomic counters, fail-open vs. fail-closed.
4. Distributed cache — consistent hashing, eviction, replication, hot keys.
5. Search autocomplete — trie with top-k, offline aggregation, serving from memory.
6. Notification system — channels, queues, retries, deduplication, providers.
7. News feed — fan-out on write vs. read, celebrities, timeline cache, ranking.
8. Chat — WebSockets, routing between gateways, ordering, offline delivery, presence.
9. Ride sharing — location ingestion, geospatial indexes, matching without double assignment.
10. Video streaming — uploads, transcoding pipeline, adaptive bitrate, CDN economics.
11. Payment system — idempotency, double-entry ledger, PSP integration, reconciliation.
12. Ticketing — the BoxOffice flash sale — the flagship: waiting room, seat holds, checkout.
13. AI assistant — RAG, LLM gateway, agents with tools, guardrails and evals.
14. Quiz — check your understanding.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

How to study a case

Every case page follows the interview framework of class 1, section by section, so you can rehearse the order until it is automatic. The timing below is for a 45-minute interview; the case pages use the same numbering.

The ten sections of each case page map onto these steps: requirements (1), estimates (2), API and data model (3), high-level design (4), deep dives (5), bottlenecks and trade-offs (6), and then three study aids — Try it in the playground, Follow-up questions and a self-assessment rubric.

How to use the playground with a case

Each case embeds the System Design Playground preloaded with its scenario. The playground is a simulator, not a benchmark: its numbers are illustrative, but the shapes (where the queue grows, when p99 bends, which component saturates first) are the ones you will see in real systems and in the labs.

flowchart LR
    p["Predict<br/>what breaks first?"] --> r["Run<br/>load / spike profile"]
    r --> o["Observe<br/>utilization, p99,<br/>errors, backlog, cost"]
    o --> c["Change one thing<br/>replicas, cache, queue,<br/>timeout, partition"]
    c --> e["Explain<br/>with the numbers<br/>of section 2"]
    e --> p

• Predict before you run. Write down which component you expect to saturate and at what load. Being wrong is the useful part.
• Change one thing at a time. Add a cache or replicas or a queue, never all three, so you know which change moved the metric.
• Use the profiles: load for steady state, spike for the BoxOffice 10:00 moment, stress and breakpoint to find the knee, chaos (or the chaos level) to kill or slow components and watch failure modes.
• Connect it to the estimates. If the page says the cache must absorb 95% of reads, look at the hit ratio; if Little's Law says 40 calls are in flight, look at the concurrency of the dependency.
• Export your design (JSON) when you like it: it is the format of the playground exercise.

The cases at a glance

Suggested order: from the easy warm-ups to the flagship. The difficulty is the usual level at which the problem is asked; every case has a senior version.

The component ids are the ones of the playground palette; each is described in the component catalog.

Patterns that repeat

After a few cases you will notice that the deep dives are drawn from a short list. Recognizing the pattern in a new problem is most of the work.

The case-studies concept map

The twelve cases are combinations of the same patterns. The map groups the cases by the pattern they share (blue), the classes that teach it, and the palette components that implement it (green); the matrix below says which classes each case tests — ● a deep dive is built on it, ○ it is part of the design, — not central. Each case page ends with its own How it connects diagram.

flowchart LR
    g1["URL shortener · news feed<br/>autocomplete · video"] --> p1["cache the hot reads<br/>(Caching, Edge)"]:::tech
    g2["notifications · video<br/>news feed · payments"] --> p2["slow work off the critical path<br/>(Messaging, Compute)"]:::tech
    g3["payments · ticketing<br/>chat · ride sharing"] --> p3["safe retries, strong consistency<br/>where it matters (Distributed, Databases)"]:::tech
    g4["chat · ride sharing<br/>ticketing · distributed cache"] --> p4["choose the partition key<br/>(Databases)"]:::tech
    g5["ticketing · rate limiter<br/>AI assistant"] --> p5["protect what cannot scale<br/>(Edge, Reliability)"]:::tech
    p1 --> k1["cache · cdn"]:::comp
    p2 --> k2["queue · kafka · worker"]:::comp
    p3 --> k3["sql · payment"]:::comp
    p4 --> k4["nosql · stream · cache"]:::comp
    p5 --> k5["waf · apigw · queue · llmgw"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

What breaks next

Nothing in the course breaks next — the next system is yours. Sixteen chapters turned one service and one database into a design where every box has a number that put it there and a price: the waiting room because 33,000 holds/s meet ~1,100, the cache because the event pages are read 100× more than they change, the circuit breaker because the provider answers in 4 s instead of 200 ms. Three places test whether that reasoning became yours. The team project builds and load-tests a system through its milestones and breaks it on purpose on the game day. The mock interviews ask for it out loud, in 45 minutes, for a system you have not seen. The design doc asks you to write it down so that someone else can disagree with a number. In all three, the question is the one every chapter asked: which number puts this box here, and what does it cost?

Related

Class 1 — interview framework · Class 2 — estimation · Interview preparation and its practice problems · Design doc exercise · Team project · Playground.

References

The case pages cite their own sources; the books below cover most of them¹²³.