Design Process | System Design Interview Handbook

🧭

The Interview Framework

5 stages · 45 minutes

A system design interview is not a test of whether you can draw the "correct" architecture. There isn't one. It's a test of how you think under ambiguity: whether you ask the right questions, whether you can back a decision with a number, and whether you notice the thing that breaks before your interviewer does.

  1. Requirements     2. Estimation      3. High-Level      4. Deep Dive        5. Wrap-Up
  ┌─────────────┐     ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
  │ Functional  │────▶│ QPS         │───▶│ Boxes and   │───▶│ Pick 1-2    │───▶│ Bottlenecks │
  │ Non-func.   │     │ Storage     │    │ arrows      │    │ components  │    │ Failure     │
  │ Scope       │     │ Bandwidth   │    │ Data flow   │    │ Go deep     │    │ modes       │
  └─────────────┘     └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
     ~5 min               ~5 min             ~10 min            ~15 min           ~10 min

💡

Treat the time budget as a guide, not a script. If the interviewer keeps steering you back to one component, that's a signal about what they want to grade you on. Follow it instead of the clock.

❓

Clarifying Requirements

functional · non-functional · scope

Functional requirements What it does

The actions a user or another service can take. Get these from the interviewer directly, don't guess.

Who are the users, and what are the two or three core actions they take?
What's explicitly out of scope for this session?
Is there an existing system this replaces, or is it greenfield?

Non-functional requirements How well it does it

These decide the entire shape of the design, so pin them down before you draw anything.

Read-heavy or write-heavy? What's the rough ratio?
Latency budget: is this on the user-facing request path, or can it be async?
Consistency: is stale data tolerable, or does every read need the latest write?
Scale: how many users, how much data, growth rate over the next year?

⚠️

Don't let this stage run long. Five minutes is enough to pin down scope and the two or three requirements that will actually drive your design. If you're still asking questions at minute ten, you're stalling.

🎯

Identifying the Bottleneck

before you design around it

Every system has one resource that runs out first: disk I/O, network bandwidth, a single database's write throughput, or a hot key that funnels traffic through one node. Find it before you propose a solution. A design that scales the wrong resource is wasted effort, no matter how clean the diagram looks.

Signals that point to the real bottleneck Diagnosis

Signal	Likely bottleneck	Direction to lean
Reads outnumber writes 100:1 or more	Database read capacity	Caching, read replicas
Writes dominate, single entity updated often	Write contention, hot row	Sharding, queueing, batching
Payloads are large (video, images, files)	Bandwidth, storage cost	Object storage, CDN
Requests fan out to many services	Tail latency, cascading failure	Timeouts, circuit breakers, parallelism
One key or user drives disproportionate traffic	Hot partition	Key salting, dedicated capacity
Strict ordering or uniqueness required	Coordination overhead	Single writer, partitioned ordering

💡

Say the bottleneck out loud before you draw the design: "this is read-heavy, so I'm going to optimize for cache hit rate over write latency." That one sentence tells the interviewer you're designing on purpose, not assembling familiar boxes.

🧱

Sketching the High-Level Design

boxes, arrows, iterate

  Client ──▶ Load Balancer ──▶ API Service ──▶ Cache ──▶ Database
                                     │                        ▲
                                     ▼                        │
                               Message Queue ──▶ Worker ───────┘

  Start here. Every box on this line should map to a requirement
  you already named. Add nothing the interviewer hasn't asked for.

Start wide and shallow: one box per major responsibility, one arrow per data flow. Narrate as you draw, so the interviewer can redirect you before you've sunk five minutes into a corner they don't care about.

A working order for the sketch Sequence

Client and entry point (load balancer, API gateway, CDN if relevant).
The service or services that own the core logic.
The datastore, and why you picked it over the alternatives.
Anything asynchronous: queues, background workers, event streams.
Only then: caching, replication, and the layers that exist purely for scale.

⚠️

Resist adding a cache, a queue, and three microservices before you've justified why the simple version fails. Complexity you can't defend under questioning reads as pattern-matching, not design.

🎛

Naming the Tradeoffs

every decision costs something

There is no free decision in distributed systems. Caching buys latency at the cost of staleness. Sharding buys write throughput at the cost of cross-shard queries. The interview isn't graded on which side you pick, it's graded on whether you can say what you gave up.

Tradeoff pairs worth having ready Reference

You choose	You pay with
Caching for read speed	Stale data, invalidation complexity
Strong consistency	Higher latency, lower availability during partitions
Sharding for write throughput	Cross-shard joins and transactions get hard
Async processing via queues	Eventual consistency, harder debugging
Microservices for team autonomy	Network calls replace function calls, more failure surface
Denormalization for read speed	Write amplification, data can drift out of sync

💡

When you propose something, finish the sentence: "I'm choosing X, which costs us Y, and I think that's the right trade because Z." That third clause is the part most candidates skip, and it's the part that separates a senior answer from a memorized one.

⚠️

Enumerating Failure Modes

before you call it done

A design isn't finished when the happy path works. It's finished when you've walked through what happens when a piece of it dies. Spend the last few minutes here even if nobody asks: it's the part that shows you've operated something in production, not just read about it.

Questions to run against your own design Checklist

What happens if any single node in this diagram goes down right now?
What happens if the network between two of your services partitions?
What happens if one client retries aggressively? Does it make things worse?
What happens if a downstream dependency slows down instead of failing outright?
Is there a single point of failure you introduced for simplicity? Say so out loud.
If this component fails, does the rest of the system degrade gracefully, or does it fail hard?

ℹ️

You don't need to solve every failure mode you name. Naming it and stating how you'd address it given more time is often enough. Silence is the only wrong answer here.

🚫

Common Mistakes

what pulls the score down

Patterns that read poorly, even with a solid design Anti-patterns

Designing before clarifying. Jumping to a diagram before you know the scale or the read/write ratio means redesigning later, in front of the interviewer.
Reciting a template. Load balancer, cache, message queue, sharded database, in that order, on every question, regardless of whether the requirements call for them.
Never doing the math. "It should scale" is not a number. Back your capacity claims with a QPS or storage estimate, even a rough one.
Going deep on one component too early. Spending fifteen minutes on database schema before the interviewer has seen the whole system leaves no time for the parts they actually wanted to probe.
Silence on tradeoffs. Presenting a design as though it has no downsides signals you haven't operated one, or haven't thought past the diagram.
Ignoring the interviewer's redirects. If they keep asking about one part, that's the part to go deep on, not a detour from your plan.

📋

Quick Reference

stage-by-stage cheat sheet

Stage	Time	Goal	Avoid
Requirements	~5 min	Pin down scope, functional and non-functional needs	Open-ended questioning with no end point
Estimation	~5 min	Rough QPS, storage, bandwidth numbers	Skipping the math entirely
High-level design	~10 min	One box per responsibility, narrated as you draw	Adding components nobody asked for
Deep dive	~15 min	One or two components, in the direction the interviewer steers	Going deep on the wrong thing for too long
Wrap-up	~10 min	Bottlenecks, failure modes, tradeoffs made explicit	Ending on the happy path with no caveats