System Design Interview — The Framework

A repeatable structure for the 45-60 minute system design round. The interviewer is watching how you think, not whether you memorized an architecture. Drive the conversation; don’t wait to be asked.

The phases (and rough timing)

Don’t sprint to a diagram. The first 15 minutes (requirements + scale + API + data) is where strong candidates separate themselves.

Phase 1 — clarify requirements

Functional — what does it do? Get the interviewer to narrow scope. “Design Twitter” is too big; “design the post + timeline read path” is a 45-min problem.

Ask:

• Who are the users? What are the core actions?
• What’s explicitly in scope vs out? (auth? media? search? analytics? — usually defer most.)
• Read-heavy or write-heavy? (decides caching, replication, fan-out strategy.)

Non-functional — the constraints that shape the design:

• Scale — users, requests/sec, data volume.
• Latency — p50/p99 targets. “Feeds load in <200ms” changes the design.
• Availability — 99.9% vs 99.99%? Multi-region?
• Consistency — strong vs eventual? Where can you tolerate staleness?
• Durability — can you ever lose data?

Write these on the board. They’re your contract — every later decision references them.

Phase 2 — estimate scale

Back-of-envelope numbers (see 02_capacity_estimation.md). The point isn’t precision — it’s deriving whether you need 1 server or 1000, one DB or a sharded fleet.

Anchor on:

• QPS — DAU × actions/user/day ÷ 86,400, then ×(peak factor ~2-3).
• Storage — items/day × size/item × retention.
• Bandwidth — QPS × payload size.
• Read:write ratio — usually 10:1 or higher for consumer apps; decisive for caching.

State the numbers out loud, round aggressively (1 day ≈ 100k seconds), and note which way you rounded.

Phase 3 — API design

A handful of operations, not a full spec:

POST /urls            { long_url }            → { short_code }
GET  /{short_code}                            → 302 redirect

POST /posts           { user_id, body }       → { post_id }
GET  /feed?user_id&cursor                     → { posts[], next_cursor }

Show you think about: pagination (cursor, not offset — see worked designs), idempotency keys on writes, what’s in the request vs derived server-side, auth boundary.

Phase 4 — data model

Entities, relationships, and crucially the access patterns:

• “Given a user, get their last 20 posts, newest first” → index / partition key choice.
• “Given a short code, get the long URL” → simple KV lookup.

Then SQL vs NoSQL falls out of the access patterns:

• Relational, joins, transactions, ad-hoc queries → Postgres.
• Known key access patterns, massive scale, predictable latency → DynamoDB.
• Don’t say “I’ll use NoSQL because it scales” — say “the access pattern is a single-key lookup at very high QPS, so a KV store fits and I avoid a relational scaling problem.”

Phase 5 — high-level architecture

Draw it. The default backbone for a web service:

Client → CDN → Load Balancer → API servers (stateless) → Cache → Database
                                      │
                                      └→ Queue → Workers (async work)

Walk a request through it. Identify where each requirement lands:

• Latency → CDN + cache.
• Availability → multiple AZs, stateless servers, DB replicas.
• Write-heavy spikes → queue to absorb.
• Read-heavy → cache + read replicas.

Keep servers stateless — session/state in Redis or the DB — so you can scale horizontally and any server handles any request.

Phase 6 — deep dive

The interviewer steers here. Common deep dives:

• The hard data structure — the timeline (fan-out on write vs read), the rate-limiter counter, the dedup store.
• Scaling the bottleneck — sharding the DB, partitioning the queue, cache invalidation.
• A specific failure — what happens when the cache dies, a worker crashes mid-job, the DB fails over.
• Consistency — how do you keep the cache and DB in sync; what does a user see during a partition.

Go deep on one or two. Show you can reason about the mechanism, not just name a service.

Phase 7 — bottlenecks & trade-offs

Close strong:

• “At 10× scale, the bottleneck becomes X. I’d address it with Y.”
• “I chose eventual consistency on the feed; the trade-off is a user might not see their own post for a second — I’d fix that with read-your-writes by serving the author from cache.”
• “This design has a single point of failure at Z; in a real system I’d add ___.”

Naming your own design’s weaknesses is a senior signal. No design is perfect; showing you see the limits beats pretending there are none.

What the interviewer is actually scoring

• Did you drive? Or wait to be prompted.
• Did you justify with the requirements? Every choice should trace back to scale/latency/consistency.
• Did you quantify? Numbers, not vibes.
• Did you go deep somewhere? Breadth-only reads as shallow.
• Did you own the trade-offs? Including the bad ones.
• Did you communicate? Think out loud; the diagram is shared, not yours.

Common mistakes

• Jumping to a diagram in minute 2 — skips requirements and scale; the design floats free of constraints.
• Buzzword salad — “I’ll use Kafka, Redis, Cassandra, microservices” with no reasoning.
• Over-engineering — designing for 1B users when they asked for 1M; or sharding before establishing you need to.
• Ignoring the interviewer’s steer — they say “tell me about the timeline” and you keep talking about auth.
• No numbers — “it’ll be a lot of traffic” instead of “~12k QPS peak.”
• Designing in silence — they can’t score what they can’t hear.
• Refusing to commit — “it depends” on everything. Make a call, state the assumption, move on.

Interview angle

• “How do you approach a system design question?” — clarify requirements (functional + non-functional), estimate scale, sketch the API and data model, draw the high-level architecture, deep-dive the hard part, then call out bottlenecks and trade-offs. Drive it; tie every decision back to the requirements.
• “They said ‘design Instagram’ — what do you do first?” — narrow scope. It’s too big for 45 minutes — ask which part matters (the photo upload + feed read path is a good 45-min slice), confirm read-heavy, get rough scale numbers, then design.
• “How do you decide SQL vs NoSQL in the room?” — derive it from the access patterns, not from “NoSQL scales.” Single-key high-QPS lookups → KV store. Joins/transactions/ad-hoc queries → relational. State the access pattern, then the choice follows.
• “What separates a senior answer from a junior one?” — quantifying with back-of-envelope numbers, going deep on a mechanism instead of just naming services, and proactively naming the design’s own weaknesses and what you’d do at 10× scale.