System design interviews terrify candidates because they seem to demand memorizing every architecture ever built. They don't. Interviewers evaluate structured reasoning under ambiguity — can you scope a vague problem, make defensible tradeoffs, and adapt when constraints shift? A repeatable framework delivers exactly that. Here it is, six steps, applicable to any prompt from "design Twitter" to "design a rate limiter."
Step 1: Clarify requirements (5 min) — where interviews are won#
Vague prompts are intentional. Jumping straight to boxes-and-arrows is the most common failure. Extract:
- Functional: what are the core operations? ("Post 280-char messages, follow users, view a timeline")
- Non-functional: scale (users? QPS?), latency targets, consistency needs, availability expectations
- Scope cuts: "Should we handle video? — I'll note it as out of scope." Explicitly excluding features is design maturity.
Memorize two back-of-envelope anchors: ~100K seconds/year makes mental math easy (10K QPS ≈ 860M requests/day), and "1M users, each with 1KB profile" style arithmetic shows you think in orders of magnitude.
Step 2: High-level design (10 min)#
Draw the boring version first: clients → load balancer → app servers → database → cache. Every real system starts here; elaborate designs are variations on it. Name components as you draw and explain data flow end-to-end for one concrete user action. Interviewers check whether you can produce a working skeleton before decorating it.
Step 3: Deep-dive the interesting components (15–20 min)#
This is the core of the interview. Pick the two or three hardest subproblems and go deep:
- Data modeling: which store fits which entity, and why (SQL vs document tradeoffs apply here too)
- The hard feature: timelines become fan-out-on-write vs fan-out-on-read; feeds become ranking pipelines; uploads become blob storage plus CDNs
- Hot paths: where will reads hammer the system? What gets cached, invalidated how?
Signal to emit constantly: "Option A gives X but costs Y; option B trades X for Z; given our read-heavy workload I'd choose B because..." There is rarely one right answer — there is only well-argued or poorly-argued.
Step 4: Scale it (10 min)#
Now the interviewer asks "what if 100x users?" Deploy the standard toolkit in order of need:
| Problem | First-line answers |
|---|---|
| Read load | Caching layers, read replicas |
| Write load | Sharding, queues buffering writes |
| Single hot entity | Consistent hashing, cache partitioning |
| Slow cross-service calls | Async processing, message queues |
Crucially: name each tool's cost. Sharding breaks cross-shard transactions; caches serve stale data; queues add latency. Candidates who present scaling tools without costs sound like they've read lists, not built systems.
Step 5: Bottlenecks and failure modes (5 min)#
Proactively ask yourself where this breaks: What happens when the database dies? When a cache stampede hits after eviction? When one shard owns a celebrity's writes? Discussing failure modes unprompted — single points of failure, retries with backoff, timeouts — is senior-level signal regardless of your actual level.
Step 6: Wrap with metrics and evolution#
Close by stating how you'd know the design works: p99 latency targets, error budgets, alert thresholds — then one sentence on what you'd build next if requirements grew. Clean endings read as experience.
Preparation that transfers#
Study canonical designs (URL shortener, chat, feed, notification system, rate limiter) not to regurgitate them but to stock your toolbox with patterns: consistent hashing, leader-follower replication, write-ahead logs, idempotency keys. Then drill the framework on novel prompts — 45 minutes weekly against a timer beats passive video watching enormously.
The secret nobody says aloud: interviewers aren't checking whether your design would survive production. They're checking whether thinking beside you for an hour would be productive. Framework + honest tradeoffs + visible adaptation = yes.
Related: the full study plan schedules this skill · Kubernetes concepts overlap heavily · live-coding communication covers the talking half
