AI can emit a working service in seconds. It cannot decide push versus pull fan-out at 500M users, or which consistency you trade away under load, and that judgment is what interviews test now. 27 problems, each worked end to end the way a Staff engineer explains them.
The bar has moved at every level: an entry-level interview and a staff design review both expect you to defend real depth, not generic boxes and arrows.
Start with the classics like the URL shortener, then work through rate limiters, distributed caches, news feeds, chat and messaging, payment systems, notification services, and ride-sharing. Every problem includes architecture diagrams, back-of-envelope math, and the follow-ups interviewers actually ask. New here? Follow the HLD Playbooks for a structured prep path.
It is rarely that you cannot name the components. It is these four gaps, and every case study here is built to close them.
They jump straight to boxes and arrows, before pinning the scale.
Every case study opens by clarifying requirements, SLOs, and back-of-envelope numbers, the way the news feed starts at 500M users and 58K reads per second.
They name components but dodge the one decision that actually matters.
Each problem makes the core call out loud and defends the trade-off, like push versus pull fan-out, instead of just adding a cache.
They have no numbers, so 'will it scale?' turns into a guess.
Back-of-envelope math in every problem, so capacity, QPS, and storage are estimates you can defend under pressure.
They freeze on the follow-ups: what breaks, where is the bottleneck, how do you 10x it?
Each case study ends with the bottlenecks, the failure modes, and the exact follow-ups interviewers ask next.
Work real problems end to end rather than memorizing definitions. For each one, clarify requirements and scale, sketch the high-level architecture, pick a data model and storage, walk the read and write paths, then discuss bottlenecks and trade-offs. The case studies on this page each follow that structure.
The classics are URL shortener, rate limiter, distributed cache, news feed, chat and messaging, notification service, web crawler, payment and digital wallet, and ride-sharing. Each is worked through in detail here.
Interviewers look for structured thinking, not a single right answer. They watch whether you clarify requirements before designing, reason about scale with rough numbers, justify each technology choice, surface bottlenecks before being asked, and discuss trade-offs honestly. Driving the conversation and handling follow-ups well matters as much as the final diagram.
A rough split for a 45-minute round: 5-10 minutes clarifying requirements and estimating scale, 10-15 minutes on the high-level architecture and data model, 15-20 minutes going deep on the read and write paths and bottlenecks, and the last few minutes on trade-offs and follow-ups. Lead with the high-level design before zooming in.
They are written to the depth a Staff or Senior engineer is expected to reach: real scaling math, concrete data models, and the second- and third-order follow-ups interviewers ask. Junior and mid-level candidates can use the same structure and go less deep on the trade-offs.
Some are free to read in full, and the complete set is part of a premium membership. Every case study includes the architecture diagram, data model, request flow, scaling math, and the trade-offs an interviewer probes for.
Follow the structured prep path, then work the 27 case studies above one by one.