The secret to system design interviews is that they are not open-ended — they follow a script. Clarify the requirements, estimate the scale, sketch the API and data model, draw a high-level design, deep-dive the one or two hard parts, then name the trade-offs. Run that loop and "design Instagram / a URL shortener / a rate limiter" all become the same seven moves with different details. This is the framework I teach, with timings for a 45-minute round, an estimation cheat-sheet you can memorize, and a calculator you can play with.
System design interviews feel intimidating because there is no single right answer. But interviewers are not grading the answer — they are grading the process: can you take an ambiguous prompt, reason about scale, and defend your decisions like a senior engineer? A framework makes that process repeatable, and repeatable is what survives interview nerves.
The 7-step framework
| Step | Time | What you do |
|---|---|---|
| 1. Clarify requirements | ~5 min | Pin functional + non-functional scope; ask, don't assume |
| 2. Estimate scale | ~5 min | Back-of-envelope: QPS, storage, read/write ratio |
| 3. Define the API | ~3 min | The handful of endpoints the system exposes |
| 4. Data model | ~4 min | Core entities + access patterns first, then pick the store |
| 5. High-level design | ~8 min | Boxes and arrows: clients → services → storage |
| 6. Deep dive | ~15 min | The 1–2 genuinely hard parts (the interview is won here) |
| 7. Bottlenecks & trade-offs | ~5 min | What breaks at 10×, and what you'd change |
1. Clarify requirements
Separate functional ("shorten a URL and redirect it") from non-functional ("highly available, sub-100 ms reads, read-heavy"). The non-functional requirements drive every later decision, so surface them now. Quantify them: not "fast" but "redirects under 100 ms at the 99th percentile"; not "reliable" but "99.99% available." Write them on the board and get the interviewer to agree — this is the contract you will be graded against.
A compact non-functional checklist to run through every time: availability (how many nines), latency (target percentile), consistency (strong or eventual, and where), durability (can we ever lose data), scale (users, QPS, data size), and the read/write ratio.
2. Estimate scale
Do the arithmetic out loud. Daily active users → requests/sec → storage over N years. You are not after precision; you are showing you can reason about whether the bottleneck is compute, storage, or network — and driving the number to a conclusion. "100 million reads a day is about 1,200 per second average, call it 12,000 at peak — that is why we need a cache, not just a database" is the move. Naming the read/write ratio early is a senior signal: it decides whether you optimize for reads (caching, replicas) or writes (sharding, queues).
You do not need a calculator — you need a few anchors and round powers of ten.
The estimation cheat-sheet
Time: a day ≈ 86,400 s ≈ 10⁵ seconds. So X per day ≈ X / 10⁵ per second. Apply a peak factor of 2–10× over the average.
Data sizes: char ≈ 1 byte · UUID ≈ 16 bytes · timestamp ≈ 8 bytes · a typical metadata row ≈ a few hundred bytes · 1 KB ≈ 10³, 1 MB ≈ 10⁶, 1 GB ≈ 10⁹, 1 TB ≈ 10¹² bytes.
Latency anchors: memory read ≈ 100 ns · SSD random read ≈ 100 µs · network within a datacenter ≈ 0.5 ms · disk seek ≈ 10 ms · cross-continent round trip ≈ 70–150 ms. Memory is roughly 1,000× faster than SSD, which is the whole reason caches exist.
Availability ("nines"): 99% ≈ 3.65 days down/year · 99.9% ≈ 8.8 hours · 99.99% ≈ 52 minutes · 99.999% ≈ 5 minutes.
Storage formula: records × bytes/record × retention-years. QPS formula: daily-events / 10⁵ × peak-factor.
Try it on your own numbers — set the scale and watch the QPS and storage fall out:
Back-of-envelope estimator
interactiveA day is about 10⁵ seconds, so events ÷ 86,400 gives QPS; multiply by a peak factor for spikes; storage is records × bytes × retention. The read:write ratio is the number that decides whether you optimize for reads (caching, replicas) or writes (sharding, queues).
3. Define the API
A few clean endpoints. This forces clarity about what the system actually does and creates the contract your design has to satisfy. Default to REST with plural resource names (POST /urls, GET /{shortCode}); reach for WebSockets or SSE when the system is genuinely real-time (chat, presence, live feeds). Derive the user from the auth token, never from the request body.
4. Data model
Name the core entities first — the nouns the system is about (users, posts, follows; or URLs and clicks) — then the access pattern, and only then the technology. "I need a key-value lookup by ID" → a KV store; "I need range queries and joins" → relational; "I need append-heavy writes and time-range reads" → a wide-column store like Cassandra. Picking a database before stating the access pattern is a classic junior mistake; stating the access pattern and letting it choose the store is the senior version of the same step.
5. High-level design
Draw the major components and the data flow between them, one API endpoint at a time. Keep it simple — clients, a load balancer, stateless services, storage, a cache. Resist over-engineering; you add a queue, a second service, or a CDN only when a specific requirement forces it, and you say which requirement. A clean diagram you can talk through beats a sprawling one you cannot.
6. Deep dive (where the interview is won)
The interviewer will push on the hard part — the part that does not scale naively. This is where you show depth, and where mid, senior, and staff candidates separate. Frame each hard choice as a Bad → Good → Great progression so the trade-offs are explicit: for unique IDs, naive prefix (collides) → hashing (collision retries) → counter + base62 (guaranteed, but needs coordination). Common deep-dive territory: sharding strategy, cache invalidation, consistency vs availability, how you avoid a single hot spot, and how the system recovers when a component dies. Spend your time here, not on the easy boxes.
7. Bottlenecks & trade-offs
Proactively name what breaks at 10× scale and the trade-offs you made — consistency vs latency, cost vs performance, 301 vs 302 redirects, SQL vs NoSQL, push vs pull. Map them to reality: "this is the fan-out-on-write vs fan-out-on-read decision Twitter makes." Interviewers love a candidate who critiques their own design before being asked; it is the clearest signal of seniority in the whole round.
The reusable building blocks
Every "design X" answer is assembled from the same dozen components. Know what each one is for and the one trade-off it carries, and most of the high-level design writes itself:
| Block | What it's for | The trade-off to name |
|---|---|---|
| Load balancer | Spread traffic across stateless servers | L4 (fast, dumb) vs L7 (smart, routing/TLS) |
| Cache (Redis/Memcached) | Serve hot reads from memory (~1,000× faster than disk) | Invalidation + staleness; warmup; eviction (LRU) |
| CDN / edge | Serve static + cacheable content near the user | Cost + invalidation across PoPs |
| Replication | Copies for read scale + failover | Replication lag → eventual consistency |
| Sharding / partitioning | Split data so no node holds it all | Hot keys; cross-shard queries are painful |
| Message queue (Kafka/SQS) | Decouple producers from consumers; absorb spikes | Async = eventual; need idempotent consumers |
| Consistent hashing | Add/remove nodes without reshuffling everything | More complex than mod-N; needs virtual nodes |
| Object store + CDN (S3) | Store large blobs (images, video) cheaply | Eventual consistency; not for low-latency metadata |
| Bloom filter | Cheap "definitely-not / maybe-yes" membership | False positives; cannot delete (basic version) |
Each of these gets a full treatment in the fundamentals pillars and the spoke walkthroughs linked below — this table is the index.
The framework on a real problem
Here is all seven steps run tight on the canonical question, a URL shortener, so you can see the loop in motion:
- Requirements — shorten a URL, redirect on lookup; highly available, redirects under 100 ms, read-heavy (~100:1).
- Estimate — 100 M new URLs/month ≈ 40 writes/s; at 100:1 that is ~4,000 reads/s (more at peak) → the read path needs a cache, the write path is trivial.
- API —
POST /urlsreturns a short code;GET /{code}returns a 301/302 redirect. - Data model — one entity (a URL mapping), pure primary-key lookup by short code → a KV store or an indexed table; shard by hash of the code.
- High-level design — client → load balancer → stateless service → cache → database; a read replica or CDN edge in front of reads.
- Deep dive — generating the short key (counter + base62 vs hashing) and scaling the read-heavy path (cache → replicas → edge). This is the whole interview.
- Trade-offs — 301 (cacheable, fast, loses analytics) vs 302 (control, every hit returns); cache stampede on a hot link; the counter as a single point of coordination.
The full URL shortener walkthrough expands every one of these into the depth an interviewer probes.
What's expected at each level
The same question is graded differently by seniority — calibrate how much the interviewer leads versus how much you drive:
- Mid-level: reach a working high-level design with prompting; pick a reasonable approach for the crux; recognize the obvious trade-offs when asked.
- Senior: drive the deep dive yourself; quantify the scale; articulate the Bad/Good/Great for the hard part; name failure modes and the read/write asymmetry without being asked.
- Staff+: lead the whole conversation; bring up multi-region, failover, and cost unprompted; reason about second-order effects (hot keys, thundering herds, consistency under partition) and product trade-offs.
Common mistakes to avoid
- Jumping to a solution before clarifying requirements or estimating scale.
- Ignoring non-functional requirements (availability, latency, the read/write ratio) — they drive the whole design.
- Picking a database before the access pattern.
- Over-engineering — adding queues, microservices, and caches no requirement asked for.
- Burning the clock on easy boxes and arriving at the deep dive with five minutes left.
- Going silent during the deep dive. Narrate; the interviewer is grading your reasoning, not just the diagram.
Worked walkthroughs: the framework on every classic problem
This is the hub. Each walkthrough below runs the same seven steps and then goes deep on where that problem is actually decided:
- Design a URL Shortener — key generation + scaling a read-heavy path.
- Design a Rate Limiter — algorithm choice + atomic distributed state.
- Design Instagram — feed fan-out, push vs pull, the celebrity problem.
- Design WhatsApp — persistent connections, delivery, and ordering.
- Design YouTube — video upload, transcoding, and streaming at scale.
- Design a Web Crawler — the URL frontier, politeness, and dedup.
And the fundamentals every one of them rests on: how a web request travels (DNS → TCP → TLS → HTTP).
Bottom line
System design interviews reward a repeatable process more than encyclopedic knowledge. Internalize these seven steps, memorize the estimation anchors, learn where the crux lives in each classic problem, and you will walk into any "design X" question with a plan instead of a blank page. The framework is the easy part to learn and the highest-leverage thing to practice — so practice it out loud, on real problems, until the loop is automatic.
Written by Amit Singh — Senior SDE at Amazon, Claude Certified Architect, and founder of AlgoEngineer. We run live mock system-design interviews with senior-engineer feedback in our System Design course.