Handbooks / System Design / Chapter 1
How to Approach a System Design Interview
7 pages · ~5 min✓ Reviewed
Start here. Next up: Networking, DNS and CDNs.
The Framework and Clarifying Requirements
1. The Framework Order
- Requirements
- Estimates
- API
- Data model
- High-level design
- Deep dives
- Bottlenecks / trade-offs
- Drive it yourself: you lead, the interviewer steers
- State the plan up front, before drawing anything
2. Functional vs Non-Functional
| Functional | Non-functional | |
|---|---|---|
| Asks | What the system does | How well it does it |
| Examples | post tweet, follow user |
Back-of-Envelope Estimation
1. The Three Formulas
| Metric | Formula | Note |
|---|---|---|
| QPS | DAU × actions per user per day ÷ 86,400 | ≈10^5 s/day |
| Storage | writes/day × item size × retention | ×3 replication |
| Bandwidth | QPS × payload size | drives CDN |
Numbers Every Engineer Should Know
1. Powers of Two
| Power | Size | ~Value |
|---|---|---|
| 2^10 | 1 KB | thousand |
| 2^20 | 1 MB | million |
| 2^30 | 1 GB | billion |
| 2^40 | 1 TB | trillion |
| 2^50 |
API Sketch, Data Model and High-Level Design
1. API Sketch
| Endpoint | Params | Response |
|---|---|---|
POST /v1/tweets | text, Idempotency-Key | 201 + id |
GET /v1/feed | cursor, limit | items + next cursor |
POST /v1/follows | followee_id | 204 |
Deep Dives, Bottlenecks and Common Mistakes
1. Deep Dives
- Pick the 1-2 hardest parts: feed fan-out, ID generation, hot keys
- Let the interviewer steer
- Go to mechanism level, not box names
2. Bottlenecks
| Walk the diagram | Fix |
|---|---|
| Single point of failure | Replication |
| Hot partition |
Cheat Sheet: Interview Framework
1. Time Split (45 min)
| Phase | Min |
|---|---|
| Requirements | 5 |
| Estimates | 5 |
| API + data model | 10 |
| High-level design | 10 |
| Deep dive | 10 |
| Wrap-up | 5 |
Check yourself
50M DAU each post 2 times a day. What are the average and peak write QPS?
- 50M × 2 = 10^8 ÷ 10^5 s ≈ 1,000 QPS average
- Peak is 2-3×, so ≈ 3,000. That is near one relational DB's limit, so plan for sharding or a queue.
Bug hunt: a candidate shards the tweets table by timestamp. What goes wrong?
- All new writes hit the newest shard, a hot shard
- Shard by a hashed ID instead, so the shard key matches the query pattern