System design interviews don't have a single correct answer — but they do have a correct process. Interviewers aren't looking for the perfect architecture; they're evaluating how you think through a complex problem: do you clarify requirements before designing? Do you reason about trade-offs rather than asserting answers? Do you know which components exist and why? This guide gives you a repeatable framework that works for any system design question, from 'Design Twitter' to 'Design a distributed key-value store.'
Who Needs to Prepare for System Design
| Role / Level | System Design Expected? | Depth |
|---|---|---|
| SWE L3 / Junior | No (usually) | Not assessed at most companies at entry level |
| SWE L4 / Mid | Sometimes | Basic components, scaling intuition, no deep distributed systems |
| SWE L5 / Senior | Yes | Full design with trade-offs, failure modes, capacity estimates |
| SWE L6 / Staff | Yes — deeper | Architecture leadership, multi-service design, tech debt awareness |
| TPM / Program Manager | Partial | High-level design literacy, not deep implementation |
| ML Engineer / Research Engineer | Yes | ML system design: training pipelines, inference serving, data pipelines |
The 8-Step System Design Framework
Step 1: Clarify Requirements (5 minutes)
Ask 3–5 clarifying questions before drawing a single box. What are the functional requirements (what does it do)? What are the non-functional requirements (availability, latency, scale)? Who are the users? What's the expected scale (DAU, QPS, data volume)? What's in scope for this session? This step demonstrates the single most important system design skill: not jumping to solutions.
Step 2: Estimate Scale (3–5 minutes)
Back-of-the-envelope calculations establish the design constraints. Example: 'If we have 100M DAUs and each user makes 10 requests per day, that's 1B requests/day, or ~12K QPS average and ~36K QPS at peak. If each request writes 1KB of data, that's 1TB/day of new data.' These numbers determine whether you need caching, what storage tier to use, and whether you need horizontal scaling.
Step 3: Define the API (3 minutes)
Write out the 2–4 core API endpoints. This forces clarity on what the system actually does and sets boundaries for the design. For a URL shortener: POST /shorten (returns short_code), GET /:short_code (redirects to original URL). Keep it simple — this is the contract the rest of the design serves.
Step 4: High-Level Design (10 minutes)
Draw the core components: clients, load balancer, application servers, database(s), cache, CDN, message queue. Don't go deep yet — establish the skeleton. Narrate as you draw: 'I'll use a load balancer in front of a horizontally-scaled application tier, with a primary database and read replicas for the heavy read load we estimated.' This is the architecture at 30,000 feet.
Step 5: Deep Dive on 1–2 Components (10–15 minutes)
Pick the most interesting or complex components and go deep. Ask the interviewer if they want to focus anywhere specific — they often have a component in mind. Common deep dives: database schema and indexing strategy, caching layer design and invalidation strategy, message queue design for async processing, write/read path for the core operation.
Step 6: Discuss Trade-offs (5 minutes)
For every major design decision, state the trade-off explicitly: 'I chose a SQL database here for ACID compliance, but if we needed to scale writes horizontally more aggressively, a NoSQL store like Cassandra would be preferable at the cost of eventual consistency.' Interviewers specifically score on whether you know there are alternatives and can reason about when each applies.
Step 7: Address Failure Modes (3–5 minutes)
What happens if the database goes down? If the cache is cold? If a message queue fills up? Strong candidates proactively address failure modes: 'If the primary DB fails, we can failover to a replica within 30 seconds — the risk is the 30-second window where writes are lost. We'd mitigate that with a write-ahead log shipped to the replica in real-time.'
Step 8: Summarise and Invite Questions (2 minutes)
Briefly recap the design: core components, key trade-offs, and open questions you'd want to answer in a real design review. Then explicitly invite the interviewer's questions — this shows confidence and keeps the conversation collaborative.
Common System Design Questions by Company
| Company | Common Questions | Key Focus |
|---|---|---|
| Design YouTube, Design Search, Design Maps, Design a distributed key-value store | Scale, efficiency, data models at massive scale | |
| Meta | Design Facebook News Feed, Design Messenger, Design Instagram, Design an ad targeting system | Social graph, fan-out, real-time messaging |
| Amazon | Design S3, Design a ride-sharing service, Design a notification system | Availability, durability, distributed systems fundamentals |
| Microsoft | Design OneDrive, Design Teams, Design a URL shortener, Design a rate limiter | Collaboration systems, enterprise scale, reliability |
| Apple | Design iCloud sync, Design App Store review system, Design a push notification service | Device constraints, privacy, applied system design |
| Stripe | Design a payment system, Design a fraud detection system, Design a rate limiter | Financial consistency, correctness, idempotency |
ML System Design — Additional Framework
ML engineer and research engineer roles include an ML-specific system design component that differs from traditional system design. The framework extends as follows:
- Problem framing: What's the ML task (classification, ranking, generation, regression)? What's the label space? How is success measured (offline: AUC, F1; online: CTR, engagement)?
- Data: What training data exists? How is it labelled? How fresh does it need to be? What are the data quality risks (label noise, distribution shift)?
- Feature engineering: What features are available? What requires computation? How are features served at inference time (pre-computed vs real-time)?
- Model architecture: What model family fits the problem? What's the trade-off between model complexity, inference latency, and accuracy?
- Training infrastructure: Where is training run? How often is the model retrained? How are experiments tracked?
- Serving infrastructure: Online (real-time) vs batch inference? What's the latency SLA? How is the model versioned and rolled back?
- Monitoring: How do you detect model degradation in production? What triggers a retrain?