What it is
High-level design questions ask you to design a full backend system — a rate limiter, a chat service, a video platform, a payment flow — starting from a one-sentence prompt and a round of clarifying questions, then working out to requirements, a component diagram, a data model, and a couple of deep dives. There is rarely a single correct architecture; the technique being tested is turning a vague goal into concrete numbers (requests per second, storage growth, latency budget) and then choosing components whose tradeoffs match those numbers, not the fanciest ones you know.
When it applies
- The prompt names a product or capability at the scale of an entire service ("design X"), not a single class or function.
- You need to reason about read/write ratios, consistency versus availability, and where state lives across multiple machines.
- A single class's internal API and object relationships within one process (an elevator controller, a parking lot, an in-memory file system) is a low-level design question instead — reach for
lld, since there's no network, no scale, and no back-of-envelope math involved.
Tells in the problem
- A one-line prompt naming a real product or capability ("design a service like...", "design the backend that...") rather than a function signature.
- An explicit scale hint ("Google scale", "a billion daily active users", "hundreds of thousands of requests per second") that expects a back-of-envelope calculation.
- A correctness or money-related constraint stated up front ("must never be lost or charged twice", "billing depends on these numbers") that signals the deep dive will be about consistency, not throughput.
- Clarifying questions are expected before any design — the prompt is deliberately under-specified about read/write mix, freshness, and failure behavior.
The classic mistake
Jumping straight to a component diagram and box names (load balancer, cache, database, queue) without first pinning down the numbers and constraints those boxes are supposed to satisfy is the failure interviewers report most — the result is a generic diagram that would look the same whether the system needs 200 writes per second or 200,000, and doesn't survive the first "why did you pick that" question. Notice yourself doing this when you can name your components before you've done any arithmetic on request volume or data size; force yourself back to the back-of-envelope math and the explicit functional/non-functional split first, and let the components fall out of those numbers.
Questions to start with
- Design a Rate Limiter — a small, well-bounded system where the whole design turns on one shared-state decision, a good first rep for the requirements-to-components flow.
- Design a URL Shortener — adds a real read-heavy/write-light split and a uniqueness constraint, the template shape for most of this hub.
- Design a Distributed Cache — shifts the deep dive toward replication and staleness tradeoffs instead of just capacity planning.
- Design a Chat Messaging System — introduces ordering and multi-device delivery guarantees on top of the read/write split.
- Design a Payment System — the twist question: correctness (no double charge, no lost money) dominates over raw scale, so the usual scaling toolbox is not the answer.