Last Updated: July 15, 2025
The 6-Step Framework
1. Requirements (3-5 min)Functional: what does it do? Non-functional: scale, latency, durability
2. Estimation (3-5 min)DAU, QPS, storage — 1M DAU × 10 req/day = ~115 QPS avg
3. API Design (3-5 min)REST endpoints, request/response shapes, error codes
4. Data Model (5 min)Tables, schemas, indexes, SQL vs NoSQL choice
5. High-Level Design (10-15 min)Boxes and arrows — services, DBs, caches, queues, CDN
6. Deep Dive (10-15 min)Critical component — scaling, failover, consistency
Estimation Cheat Sheet
| Metric | Formula |
|---|---|
| QPS | DAU × avg_req_per_day ÷ 86400 |
| Peak QPS | QPS × 2-3x peak-to-average ratio |
| Storage/day | QPS × 86400 × avg_request_size |
| Storage/year | Storage/day × 365 |
| Cache size | Daily data × 0.2 (Pareto: 20% gets 80% traffic) |
| Bandwidth | Peak QPS × avg_response_size |
Common Questions & Patterns
| Question | Key Pattern |
|---|---|
| Design a URL shortener | Hash function, Base62, KV store, cache |
| Design a chat system | WebSocket, message queue, pub/sub |
| Design a news feed | Fan-out on write vs read, ranking, cache |
| Design a rate limiter | Token bucket, sliding window, Redis |
| Design a distributed key-value store | Consistent hashing, replication, quorum |
What Interviewers Look For
| Signal | Good | Bad |
|---|---|---|
| Communication | Think out loud, ask clarifying questions | Silent for 5 minutes, then present solution |
| Tradeoffs | "Here are 3 options, I'd pick X because..." | "This is the right way" |
| Breadth | Touch all layers: client, API, data, infra | Only talk about database schema |
| Pragmatism | Start simple, iterate based on bottlenecks | Over-engineered from minute one |
Pro Tip: Always start with requirements — 80% of failed system design interviews are because the candidate started designing before clarifying what to build. Ask: users, features, scale.