The System Design Interview: A Repeatable Framework

Why structure beats knowledge

A senior interviewer is not grading whether your design is the right one — there isn't one. They're watching how you think: do you clarify before you build, do you reason about trade-offs, do you know where the bottlenecks are. A candidate who calmly walks a clear path through an average design usually outscores one who knows more but jumps around. Structure is the signal.

A framework you can run every time

Spend your time roughly in this order. The percentages matter more than the exact minutes.

1. Clarify requirements (~15%). Separate functional ("users can post and follow") from non-functional (scale, latency, consistency, availability). Ask for rough numbers: how many users, reads vs writes, payload sizes.
2. Estimate the scale (~10%). Do back-of-the-envelope math: requests per second, storage per year, bandwidth. It sets the whole design — 100 RPS and 1M RPS are different problems.
3. Define the API and data model (~15%). A handful of endpoints and the core entities. This anchors everything that follows.
4. Draw the high-level design (~25%). Client, load balancer, service(s), database, cache, queue. Keep it simple first — you'll add depth where asked.
5. Go deep where it matters (~25%). Pick the interesting bottleneck — the hot read path, the write fan-out, the storage choice — and drill in. This is where senior signal lives.
6. Address bottlenecks and trade-offs (~10%). Single points of failure, hotspots, consistency vs availability. Name what you'd monitor.

The levers you'll reach for

Almost every design is assembled from the same handful of pieces. Know when each earns its place:

• Caching — cut read latency and DB load; think about invalidation and staleness.
• Load balancing — spread traffic; horizontal scale of stateless services.
• Replication — availability and read scaling; introduces consistency lag.
• Sharding / partitioning — scale writes and storage past one machine; watch for hot shards.
• Queues — decouple producers from consumers; smooth spikes; enable async work.
• CDN — push static and cacheable content near users.

The skill isn't listing these — it's justifying which ones the problem actually needs, and what each one costs.

Six questions that come up again and again

If you can confidently design these, you're ready for most variations:

• Design a URL shortener (key generation, redirect read path, analytics).
• Design a news feed (fan-out on write vs read, ranking, hot users).
• Design a chat / messaging system (delivery guarantees, presence, ordering).
• Design a rate limiter (token bucket, distributed counters).
• Design a file storage / sharing service (metadata vs blobs, dedup, consistency).
• Design a ride-hailing or nearby-search service (geospatial indexing, matching).

These recur because each one forces a distinct trade-off — write fan-out, geospatial indexing, delivery semantics. For a deeper walkthrough of how a live assistant structures answers to prompts like these, see our system design interview AI page.

Mistakes that quietly cost you

• Building before clarifying. Jumping to a database schema before you know the read/write ratio signals inexperience.
• Staying shallow everywhere. Touching ten components for thirty seconds each shows no depth. Go deep on one.
• Ignoring numbers. "It'll scale" means nothing without an estimate behind it.
• No trade-offs. Every choice has a cost. Saying "I'd use a cache, but it adds staleness we'd bound with a short TTL" is the whole game.
• Silence. The interviewer can only grade what you say out loud. Narrate your thinking.

How to practice

Pick one prompt from the list above and run the full framework end to end, out loud, in forty-five minutes — ideally whiteboard or a blank doc, no notes. Record yourself or grab a peer. Review where time actually went: most people discover they spent thirty minutes on the data model and never reached scaling. Do this five times across different problem types and the structure becomes muscle memory — which is exactly what frees you to think on the day.