System Design Interview Framework
ð Concept
The system design interview is 45-60 minutes of structured discussion. Here's the framework that top candidates use.
The 4-Step Framework
Step 1: Requirements Clarification (5-7 min)
Ask questions. Don't jump into design.
Functional requirements: What does the system DO?
- Core features (MVP)
- Who are the users? How many?
- What are the main use cases?
Non-functional requirements: What are the constraints?
- Scale: How many users/requests?
- Latency: What response time is acceptable?
- Availability: How many nines? (99.9%? 99.99%?)
- Consistency: Can data be eventually consistent?
Step 2: Back-of-Envelope Estimation (3-5 min)
Show you can think about scale with rough math.
- Traffic: QPS (queries per second) for read and write
- Storage: How much data over 5-10 years
- Bandwidth: Data transfer rates
- Memory: Cache size estimation (80/20 rule)
Step 3: High-Level Design (15-20 min)
Draw the architecture. Walk through the main flow.
- API design: Define the key endpoints
- Data model: What tables/collections, what fields
- Architecture diagram: Show the main components and data flow
- Core algorithm: The key logic (e.g., feed ranking, URL encoding)
Step 4: Deep Dive (15-20 min)
The interviewer will ask you to drill into specific areas:
- "How would you handle this failure scenario?"
- "What happens at 100x the current scale?"
- "How do you ensure consistency here?"
This is where you showcase depth. Discuss trade-offs, alternatives, and why you chose your approach.
Key Numbers to Know
| Resource | Speed |
|---|---|
| L1 cache reference | 0.5 ns |
| RAM access | 100 ns |
| SSD random read | 150 Ξs |
| HDD seek | 10 ms |
| Send 1 MB over 1 Gbps network | 10 ms |
| Read 1 MB from SSD | 1 ms |
| Read 1 MB from HDD | 20 ms |
| Round trip within datacenter | 0.5 ms |
| Round trip CA â Netherlands | 150 ms |
Estimation Cheat Sheet
| Quantity | Approximate Value |
|---|---|
| Seconds in a day | 86,400 â 100,000 |
| Requests per day at 1 QPS | ~100K/day |
| 1 million requests/day | ~12 QPS |
| 1 billion requests/day | ~12K QPS |
| 1 byte | 8 bits |
| 1 KB | 1,024 bytes â 1,000 |
| 1 MB | 1 million bytes |
| 1 GB | 1 billion bytes |
| 1 TB | 1 trillion bytes |
Pro tip: Practice talking through your design out loud. The interview is as much about communication as technical depth. Explain your reasoning, not just your decisions.
ðŧ Code Example
1// ============================================2// Interview Preparation â Practice Template3// ============================================45// ---------- Back-of-Envelope Estimation Template ----------67function estimateSystem(params) {8 const {9 dau, // Daily Active Users10 actionsPerUser, // Actions per user per day11 avgPayloadBytes, // Average request/response size12 readWriteRatio, // Read:Write ratio (e.g., 10 means 10:1)13 retentionYears, // How long to keep data14 cacheHitRatio, // Expected cache hit rate (0.8 = 80%)15 } = params;1617 const SECONDS_PER_DAY = 86400;1819 // Traffic estimation20 const totalActions = dau * actionsPerUser;21 const totalQPS = Math.ceil(totalActions / SECONDS_PER_DAY);22 const writeQPS = Math.ceil(totalQPS / (1 + readWriteRatio));23 const readQPS = totalQPS - writeQPS;24 const peakQPS = totalQPS * 3; // Assume 3x peak2526 // Storage estimation27 const dailyStorage = totalActions * avgPayloadBytes;28 const yearlyStorage = dailyStorage * 365;29 const totalStorage = yearlyStorage * retentionYears;3031 // Bandwidth32 const incomingBandwidth = writeQPS * avgPayloadBytes;33 const outgoingBandwidth = readQPS * avgPayloadBytes;3435 // Cache estimation (80/20 rule)36 const dailyUniqueRequests = totalActions * 0.2; // 20% unique37 const cacheMemory = dailyUniqueRequests * avgPayloadBytes;3839 return {40 traffic: {41 totalQPS,42 readQPS,43 writeQPS,44 peakQPS,45 note: `\${dau.toLocaleString()} DAU Ã \${actionsPerUser} actions = \${totalActions.toLocaleString()} actions/day`,46 },47 storage: {48 daily: formatBytes(dailyStorage),49 yearly: formatBytes(yearlyStorage),50 total: formatBytes(totalStorage),51 note: `\${retentionYears} years retention`,52 },53 bandwidth: {54 incoming: formatBytes(incomingBandwidth) + '/sec',55 outgoing: formatBytes(outgoingBandwidth) + '/sec',56 },57 cache: {58 size: formatBytes(cacheMemory),59 hitRate: `\${cacheHitRatio * 100}%`,60 note: '80/20 rule â cache top 20% of requests',61 },62 };63}6465function formatBytes(bytes) {66 const units = ['B', 'KB', 'MB', 'GB', 'TB', 'PB'];67 let i = 0;68 let val = bytes;69 while (val >= 1000 && i < units.length - 1) { val /= 1000; i++; }70 return `\${val.toFixed(1)} \${units[i]}`;71}7273// ---------- Example: Twitter Estimation ----------74console.log('\n=== Twitter Estimation ===');75console.log(estimateSystem({76 dau: 300_000_000,77 actionsPerUser: 5, // 5 actions (post, read, like)78 avgPayloadBytes: 500, // 500 bytes per tweet79 readWriteRatio: 100, // 100 reads per 1 write80 retentionYears: 10,81 cacheHitRatio: 0.80,82}));8384// ---------- Example: URL Shortener Estimation ----------85console.log('\n=== URL Shortener Estimation ===');86console.log(estimateSystem({87 dau: 10_000_000,88 actionsPerUser: 1, // 1 URL shortened per day89 avgPayloadBytes: 200, // URL + metadata90 readWriteRatio: 10, // 10 redirects per 1 creation91 retentionYears: 10,92 cacheHitRatio: 0.90,93}));9495// ---------- Interview Checklist ----------96const interviewChecklist = {97 'Step 1: Requirements (5-7 min)': [98 'Clarify functional requirements (core features)',99 'Clarify non-functional requirements (scale, latency, consistency)',100 'Identify users and use cases',101 'Agree on scope with interviewer',102 ],103 'Step 2: Estimation (3-5 min)': [104 'Calculate QPS (read and write)',105 'Calculate storage requirements',106 'Calculate bandwidth',107 'Calculate cache size',108 ],109 'Step 3: High-Level Design (15-20 min)': [110 'Define API endpoints',111 'Design data model (schema)',112 'Draw architecture diagram',113 'Walk through the main data flow',114 'Explain key design decisions',115 ],116 'Step 4: Deep Dive (15-20 min)': [117 'Address scaling challenges',118 'Discuss failure scenarios',119 'Explain consistency vs availability choices',120 'Mention monitoring and observability',121 'Discuss trade-offs of your design',122 ],123};124125console.log('\nInterview Checklist:', interviewChecklist);
ðïļ Practice Exercise
Timed Practice: Set a 45-minute timer and design one of: YouTube, Uber, Dropbox, Google Docs, Instagram. Follow the 4-step framework strictly.
Estimation Drills: Practice back-of-envelope calculations for: (a) Instagram (2B users, 100M photos/day), (b) Google Maps (1B users, 1K tile requests per session), (c) Slack (20M DAU, 50 messages per user per day).
Trade-off Analysis: For each pair, explain when you'd choose each and why: (a) SQL vs NoSQL, (b) REST vs gRPC, (c) Push vs Pull feed, (d) Strong vs Eventual consistency, (e) Monolith vs Microservices.
Curveball Practice: After designing a system, practice answering: "What if traffic increases 100x overnight?", "What if your primary database goes down?", "How would you handle this in multiple regions?"
Communication Practice: Record yourself walking through a design. Review the recording for: clarity, structure, unnecessary pauses, and missed trade-off discussions.
â ïļ Common Mistakes
Jumping into design without clarifying requirements â the interviewer wants to see that you ask the right questions. Spend 5-7 minutes clarifying scope, scale, and constraints.
Not doing back-of-envelope math â estimation shows you think quantitatively. 'A lot of traffic' is vague. '50K QPS with 3x peak' is specific and impressive.
Drawing a perfect architecture without explaining trade-offs â the interviewer doesn't want the 'right answer' (there isn't one). They want to see you reason about trade-offs.
Not talking enough â system design interviews are collaborative discussions. The interviewer can't evaluate your thinking if you're silently drawing. Narrate your thought process.
Over-engineering the first pass â start simple (single server) and scale up when the interviewer asks about scale. Don't start with Kubernetes, Kafka, and 50 microservices.
ðž Interview Questions
ðĪ Mock Interview
Practice a live interview for System Design Interview Framework