The method · system design interview
The whole method on one page: how to run the hour and the seven steps, requirements, estimation, API, data, high-level design, deep dives, trade-offs. This is the umbrella the eight worked designs all apply, and the spine the whole course teaches. Bring it to any "design X" prompt.
A system design interview tests how you decide under ambiguity, not how many components you can name. The interviewer scores whether you scope the problem, drive a structured path, justify choices with numbers, and name the trade-offs out loud. Follow the steps, think aloud, and let the requirements (not a memorized diagram) shape the design.
The same seven steps every time, in order, with a rough time budget so you reach trade-offs (the part that scores) before the clock runs out. Drive it; do not wait to be led.
| # | Step | Output | ~ time |
|---|---|---|---|
| 1 | Requirements & scope | functional + non-functional, explicit out-of-scope | 5 min |
| 2 | Estimation | the one number that bounds the design | 5 min |
| 3 | API | the handful of endpoints | 5 min |
| 4 | Data & stores | entities + store choice from access patterns | 7 min |
| 5 | High-level design | boxes and data flow | 8 min |
| 6 | Deep dives | the 2 to 3 hard parts, in detail | 15 min |
| 7 | Trade-offs | decisions named along the axes | 5 min |
Spend the first ten minutes narrowing (requirements + the bounding number), the middle on the spine (API, data, diagram), and the back half on the 1 to 3 things that are actually hard (deep dives) and the trade-offs. Most candidates over-build the easy parts and never reach the hard ones; you do the opposite.
Never start drawing. First, bound the problem: what it must do, what shape it must be, and just as importantly, what it does not do.
The few verbs that carry the product. For a feed: post, follow, read the timeline. Cut to the spine and say the rest is out of scope.
The shape: read vs write ratio, latency target, consistency, availability, scale. These drive the architecture more than the feature list does.
Ask 2 to 3 sharp clarifying questions, then state your scope and assumptions out loud: "I will design the home timeline, read-heavy, eventual consistency is fine, hundreds of millions of users; search and DMs are out of scope." That one sentence shows you scope under ambiguity, which is half of what is being tested. Maps to S2.
Find the single number that decides the architecture, before you draw anything. It is rarely raw QPS; it is the asymmetry that forces a structure.
useful back-of-envelope anchors seconds/day ~ 86,400 ~ 10^5 1M req/day ~ 12 req/sec | 1B req/day ~ 12k req/sec read:write ratio | peak ~ 2 to 10x average storage = item_size * items | fan-out = followers per write ask: what is the ONE number that shapes this design? Twitter -> fan-out amplification (1 tweet = N timeline writes) Uber -> location writes/sec (a firehose of ephemeral updates) YouTube -> egress bandwidth (serving, not requests) Stripe -> the error budget is zero (correctness, not QPS)
Not arithmetic precision, but whether you can find the constraint that drives the design and reason about scale with round numbers. Name it explicitly ("the deciding number here is...") and let it justify your later choices. Maps to S2 and the estimation cheat sheet.
Name the handful of endpoints that carry the product, not every route. The API makes the requirements concrete and sets up the data model.
just the spine, e.g. a feed: POST /tweets create (idempotency key) POST /follows follow GET /timeline?cursor= read (cursor pagination, hydrated) good instincts to show: - idempotency key on non-idempotent writes (safe retry) - cursor pagination, not offset (stable, fast at depth) - one round trip: return hydrated objects, not ids to re-fetch
A clean, minimal contract that shows API instincts (idempotency, pagination, one round trip) without bikeshedding field names. Three or four endpoints is plenty. Maps to S5 and the API cheat sheet.
List the core entities, then pick a store for each from its access pattern, not from habit. This is where read/write shape becomes a concrete decision.
| Access pattern | Reach for |
|---|---|
| Relational, transactional, joins | Relational (Postgres) |
| Huge, immutable, point lookups by key | Wide-column / KV (Cassandra, Dynamo) |
| Hot, ephemeral, fast reads | In-memory (Redis) |
| Large blobs (media, files) | Object storage + CDN |
| Full-text / ranked retrieval | Inverted index (search engine) |
Say the access pattern, then the store, then the justification: "timelines are hot and disposable, so Redis; tweets are immutable and huge, so a sharded KV." Picking a store from the access pattern is the whole skill. Maps to S3, S4, and the data-stores cheat sheet.
Now the boxes and arrows: client, load balancer, services, stores, caches, queues, and the data flow between them. Keep it legible; this is the map you will deep-dive into.
client -> CDN / LB -> service(s) -> cache -> database
| \-> queue -> workers (async)
\-> other services
draw the two paths that matter most, usually:
WRITE path (often async, fan-out, persistence)
READ path (often cached, must be fast)
separate them on the board; it makes the design legible and
sets up the deep dives.
A clear diagram with the right primitives (LB, cache, queue, store) and a sensible data flow, drawn so the hard parts are visible. Do not over-decorate; a legible monolith-to-services sketch beats a maze. Maps to S7.
Pick the 1 to 3 genuinely hard parts and go deep. This is the bulk of the score: it is where senior judgement shows. The interviewer often steers you here, so leave time.
| If the design has… | The likely deep dive |
|---|---|
| A feed / fan-out | fan-out on write vs read, the celebrity hot key |
| Realtime delivery | persistent connections, ordering, delivery semantics |
| Money / inventory | idempotency, atomic claims, exactly-once, no double-spend |
| Huge reads | caching, CDN, the long tail and hot keys |
| Failure exposure | blast radius, fail-open vs fail-closed, degradation |
Name the hard part, sketch the naive approach, show why it breaks at scale, then present the fix and its cost. "Naive fan-out-on-write breaks for celebrities; hybrid push-for-most, pull-for-few fixes it, at the cost of a read-time merge." That arc, problem to scaled solution to cost, is exactly what scores. Maps to S6 and S9.
Close by naming the decisions you made along the core axes, and the least-wrong call for each. This is the single highest-signal thing you do.
| Axis | The question to answer out loud |
|---|---|
| Consistency vs availability | can this read be stale, or must it be exact? |
| Latency vs cost | what do you precompute / cache to be fast? |
| Read vs write optimisation | which side dominates, and did you optimise it? |
| Space vs time | what do you store redundantly to save compute? |
| Simplicity vs capability | what did you ship simple and defer? |
| Coupling vs cohesion | what did you decouple (a queue, a boundary) and why? |
The interviewer is grading a few specific behaviours. Aim at these directly.
What scores
What sinks you
Each of the eight worked designs runs these exact seven steps end to end: Twitter, WhatsApp, Stripe, Uber, YouTube, Dropbox, Google Search, Ticketmaster. Read one alongside this sheet to see the framework in motion.
The ways strong engineers still lose the room, and the habit that prevents it.
The traps
The repeatable move
1. scope: requirements + the bounding number
2. spine: API, data, one clear diagram
3. depth: 2 to 3 hard parts, problem to fix to cost
4. trade-offs: name the call on each axis
The whole hour in four moves. Drive them in order, think aloud, and let the requirements (not a template) shape the design. That is the difference between reciting components and doing the job.
Scope it, find the bounding number, build the spine, go deep on the hard parts, and name the trade-offs out loud. This sheet is the method the whole course teaches, and the eight worked designs are it, applied. Bring it to any "design X" and you will never face a blank board again.
The umbrella for the eight worked designs and the From Senior to Staff sessions. Further reading: System Design Primer · common prompts · estimation cheat sheet · the full course.