SD Interview Framework & Pitfalls
The Standard Framework
Applies to every HLD problem in this KB — see each problem page for it applied end-to-end.
- Clarify requirements — functional (what it does, explicitly cut what it doesn't) + non-functional (scale, latency SLO, consistency needs, availability target). Spend the first ~10% of the interview here; designing without constraints is the single most common failure mode.
- Estimate scale — QPS (read + write, separately), storage growth per year, bandwidth. Show the arithmetic — the number matters less than proving you can derive it.
- API design — the handful of endpoints that define the contract.
- High-level architecture — components + data flow, walked through for one read and one write.
- Deep dive the hard part — every problem has exactly one sub-problem that's actually hard (ID generation, fanout, delivery guarantees, consistency under concurrent writes). Spend the largest single chunk of remaining time here.
- Scaling, bottlenecks, failure modes — sharding key + its hotspot risk, caching strategy + hit-rate reasoning, what happens when each major component dies.
Evaluation Criteria
Judge every proposed design against three criteria, not "is it impressive":
- Simplicity — as simple as the requirements allow, not maximally sophisticated.
- Fidelity — actually covers the stated functional + non-functional requirements.
- Cost-effectiveness — is the infrastructure spend justified by the actual scale?
Scalability Evolution (how the pieces assemble as scale grows)
| Scale | Pattern | Key addition |
|---|---|---|
| ~1K users | Monolith | Single server, app + DB together |
| ~10K users | Vertical scale + cache | Bigger instance, read replica, Redis cache |
| ~100K users | Horizontal scale | Load balancer, multiple app servers, CDN for static assets |
| 1M+ users | Distributed system | API gateway, microservices, message queue, DB sharding, multi-region cache |
The common failure mode is starting at the right column for a product with left-column traffic — Instagram famously ran a monolith well past the point most engineers assume you need microservices. Match the architecture to the actual numbers, not to what FAANG blog posts describe.
Common Pitfalls (name these proactively, don't wait to be caught)
| Pitfall | What it looks like | Fix |
|---|---|---|
| Premature optimization | Designing Kafka + sharding + multi-region for a product with 10K users | Start simple; add complexity only when back-of-envelope numbers prove the current design has hit a real limit |
| Pattern-matching without justification | Adding a cache/queue/CDN because you've seen it in other designs, not because your numbers demand it | For every component added, state its latency cost, dollar cost, and failure mode — if you can't, you don't need it yet |
| Ignoring operational reality | An elegant whiteboard design that's a nightmare to run — who's on call, how do you debug it, what's the blast radius of a bad deploy | Discuss monitoring/observability explicitly, even briefly |
| Treating averages as the whole latency picture | "Average latency is 20ms" | Always reason in p95/p99 — tail latency is what users actually feel and what breaks SLAs |
| Hot key / hot shard blindness | "We'll just add more cache nodes" when one key gets 90% of traffic | Uniform capacity doesn't fix a skewed access pattern — see request collapsing, local caching, adaptive hot-key promotion in [[Caching & Redis]] |
Interview Drill
Q: An interviewer asks you to design a system and gives almost no constraints. What do you do first? A: Don't start drawing boxes — spend the first few minutes actively clarifying functional scope and non-functional targets (scale, latency, consistency needs). Designing without stated constraints is the most common way candidates lose points early, because every later decision (cache? shard? queue?) is only justifiable relative to a number you haven't established yet.
Cross-links
[[Core Vocabulary & Quality Pillars]] · [[Senior SD Mindset]] · [[Design a URL Shortener]] · [[Rate Limiter]]