If you've done a handful of system design interviews, you've probably noticed something: the candidates who do well aren't always the ones who know the most about distributed systems. They're the ones who impose the same structure on every answer, no matter what's thrown at them.
Interviewers are pattern-matching for structure as much as they're checking your technical correctness. Here's the framework worth having ready before you walk in.
The 5 Steps
1. Clarify requirements (3-5 min)
Functional requirements (what the system must do), non-functional requirements (scale, latency, availability, consistency), and explicit out-of-scope items. Ask, don't assume — jumping straight to a design before this step is one of the fastest ways to lose points early.
2. Estimate scale (3-5 min)
Users, QPS (split read vs write), data volume, growth rate. Round numbers are fine. What matters is that you show your math out loud rather than silently assuming a number.
A couple of shortcuts worth memorizing:
- 1 million requests/day ≈ 12 requests/sec average (peak is usually 2-3x that)
- Storage for N years ≈ daily volume × 365 × N (and say whether you're including replication factor)
3. High-level design (10-12 min)
Draw the boxes: client, load balancer, API layer, service(s), cache, database, queue. Walk through one request end-to-end before you add detail — this gives the interviewer a mental model to hang the rest of the conversation on.
4. Deep dive (12-15 min)
This part is usually interviewer-led. They'll steer you toward whatever they want to probe — the data model, a specific hard component, a failure scenario. Follow their lead; that's the signal of what they actually want to evaluate.
5. Trade-offs and wrap-up (5-7 min)
State what you'd change at 10x scale, what you deliberately deferred, and 1-2 alternatives you considered and rejected — and why. This is the step people run out of time for most often, so watch the clock and wrap up deliberately around minute 40.
Why saying the step names out loud matters
It sounds like a small thing, but narrating "okay, let me clarify requirements first" before you start signals organization to the interviewer before you've said anything technical yet. It also protects you: if you get stuck mid-answer, you and the interviewer both know exactly where you are in the process and what's left to cover.
A worked example: News Feed / Timeline
Quick pass through the framework on a common prompt — "design a news feed."
- Requirements: personalized, roughly-reverse-chronological feed from accounts a user follows. Non-functional: low read latency, eventual consistency is fine.
- Scale: assume 100M users, heavy read:write skew (typical for feeds, often 100:1+).
- High-level design: client → feed service → cache (Redis) → database. The core question is fan-out.
- Deep dive (this is where it usually goes): fan-out-on-write (precompute feeds, fast reads, expensive for high-follower accounts) vs fan-out-on-read (cheap writes, slow for heavy followers). The strong answer is a hybrid — fan-out-on-write for typical users, fan-out-on-read for accounts above a follower threshold.
- Trade-offs: caching strategy, how ranking (beyond pure recency) would layer on top without recomputing on every read.
That's the whole shape. Swap "news feed" for rate limiter, chat system, or URL shortener, and the same 5 steps still apply — only the deep-dive content changes.
Taking this further
I turned this framework into a full cheat sheet with capacity-estimation numbers and playbooks for 10 common patterns (URL shortener, rate limiter, chat systems, notification systems, distributed cache, video streaming, ride-sharing, autocomplete, key-value stores, and news feeds) — each with likely deep-dive questions and trade-offs to have ready. If that's useful, it's here.
Either way, hope the framework itself helps. Happy to answer questions in the comments if you're prepping for something specific.
Top comments (0)