System Design Interview Overview
System design interviews test your ability to design large-scale distributed systems from scratch. Unlike coding interviews, there's no single correct answer — interviewers evaluate your thought process, communication, and knowledge of trade-offs.
What Interviewers Are Looking For
| Skill | Description |
|---|---|
| Scoping | Can you clarify requirements and define the problem clearly? |
| Estimation | Do you have intuition for scale and capacity? |
| Architecture | Can you design a system with clear components? |
| Trade-offs | Do you understand the pros/cons of each choice? |
| Communication | Can you explain complex systems simply? |
| Depth | Can you go deep on any component when asked? |
The 4-Step Framework
Use this framework for every system design question:
Step 1: Clarify Requirements (5 minutes)
Never start designing before understanding what you're building.
Functional requirements — What should the system do?
- What are the core features?
- What can we ignore for this interview?
Non-functional requirements — How should it behave?
- How many users? DAU (daily active users)?
- Read-heavy or write-heavy?
- Consistency vs. availability trade-off?
- Latency requirements?
- Data size and growth rate?
Example for "Design Twitter":
- Users can post tweets (up to 280 characters)
- Users can follow other users
- Users can see a home timeline (tweets from people they follow)
- 100M DAU, 50M tweets/day, 500M timeline reads/day
- Eventual consistency is acceptable for timelines
- P99 latency for timeline < 200ms
Step 2: Estimate Scale (5 minutes)
Back-of-the-envelope calculations help you make the right architectural decisions.
Key numbers to remember:
| Operation | Approximate time |
|---|---|
| L1 cache read | 1 ns |
| L2 cache read | 4 ns |
| RAM read | 100 ns |
| SSD read | 16 µs |
| HDD read | 2 ms |
| Network round trip (same DC) | 0.5 ms |
| Network round trip (cross-DC) | 150 ms |
Key data sizes:
| Item | Size |
|---|---|
| Tweet | ~300 bytes |
| User profile | ~1 KB |
| Photo | ~300 KB |
| Video (1 min) | ~50 MB |
Example calculation for Twitter:
Writes: 50M tweets/day = ~600 tweets/sec = ~1,200 tweets/sec at peak (2× average)
Reads: 500M timeline reads/day = ~6,000 reads/sec = ~60,000 reads/sec at peak
Storage:
- 50M tweets/day × 300 bytes = 15 GB/day of tweet data
- 3 years: 15 GB × 365 × 3 ≈ 16 TB (manageable on a large DB cluster)
Bandwidth:
- 1,200 tweets/sec × 300 bytes = 360 KB/sec write bandwidth
- 60,000 reads/sec × 300 bytes = 18 MB/sec read bandwidth
Step 3: Design the System (20-25 minutes)
Start high-level, then go deep where it matters.
High-level architecture template:
[Client] → [Load Balancer] → [API Gateway] → [Service Layer] → [Database]
↕
[Cache Layer]
↕
[Message Queue]
↕
[Worker Services]
Key components to cover:
- API design — What endpoints does the system need?
- Data model — What tables/collections, and how are they related?
- Database choice — SQL or NoSQL? Why?
- Caching strategy — What to cache, where, and how to invalidate?
- Scalability — How does the system handle 10× growth?
Step 4: Deep Dives (10-15 minutes)
The interviewer will ask you to go deep on specific components. Common deep-dive topics:
- Database design — Sharding strategy, indexing, query optimization
- Caching — Cache invalidation, cache-aside vs. write-through
- Message queues — Kafka vs. SQS, exactly-once delivery
- Search — Elasticsearch, inverted indexes
- CDN — Edge caching, cache invalidation
- Rate limiting — Token bucket, sliding window algorithms
Common System Design Topics
Core Building Blocks
| Component | When to Use |
|---|---|
| SQL Database (PostgreSQL, MySQL) | Strong consistency, complex queries, transactions |
| NoSQL Document Store (MongoDB) | Flexible schema, hierarchical data |
| NoSQL Key-Value (Redis, DynamoDB) | High-speed reads, simple access patterns |
| NoSQL Wide-Column (Cassandra) | Time-series, high write volume |
| Message Queue (Kafka, RabbitMQ) | Async processing, event streaming |
| Object Storage (S3) | Binary data, media files |
| CDN (CloudFront, Fastly) | Static assets, geographic distribution |
| Search Engine (Elasticsearch) | Full-text search, analytics |
| Cache (Redis, Memcached) | Hot data, session storage |
System Design Problems in This Guide
- Design a URL Shortener (TinyURL) — Great starter problem
- Design Twitter's Feed — Fan-out on write vs. read
- Design WhatsApp/Chat System — WebSockets, message delivery
- Design Netflix/Video Streaming — CDN, encoding, chunking
- Design Uber/Ride-sharing — Location services, matching
- Design a Rate Limiter — Algorithms and distributed state
- Design a Search Engine — Crawling, indexing, ranking
- Design a Key-Value Store — Custom database internals
Common Mistakes to Avoid
❌ Starting to code — System design is about diagrams and discussion, not code ❌ Not asking clarifying questions — Never assume requirements ❌ Only describing the happy path — Talk about failure modes and recovery ❌ Ignoring data volume — Scale determines architecture ❌ Being too attached to one solution — Show you understand trade-offs ❌ Going too deep too early — Stay high-level until asked to dive deep ❌ Staying silent — Think out loud; interviewers need to hear your reasoning
Resources
- Designing Data-Intensive Applications by Martin Kleppmann — The bible of distributed systems
- System Design Primer — Free GitHub resource
- Grokking the System Design Interview — Popular course