Core idea
Estimation is a communication skill, not a math test. The goal is to show you can reason from first principles to reasonable numbers, and use those numbers to make design decisions.
Mental model
Framework: Start with users → derive requests → derive data. 1M daily active users → average 10 requests/day → 10M requests/day → 115 QPS. Peak is 2–3x average. Storage: 1M users × 1 post/day × 1KB = 1GB/day = 365GB/year. Always round aggressively.
Why it matters
- Tells you whether you need 1 server or 100
- Reveals whether you need caching, sharding, CDN before you even start designing
- Shows the interviewer you think like an engineer not a student
What to know
- QPS = (DAU × requests_per_user) / 86400
- Storage/year = DAU × writes_per_day × avg_size × 365
- Bandwidth = QPS × avg_response_size
- Always state: peak = 2–3x average QPS
- Memory for cache: hot 20% of data (Pareto principle)
Common traps
- Getting lost in precision — wrong order of magnitude matters, wrong digit doesn’t
- Forgetting peak traffic — design for peak, not average
- Not using your estimates to drive decisions — they must inform your architecture
Recognise it
Recognition trigger: Before drawing any diagram, clarify then estimate. Estimates tell you: do I need a cache? Do I need to shard? Is this read-heavy or write-heavy? Those answers change the entire architecture.
Practice question
Design a URL shortener for 100M users. Start with estimation.
Apply at work
Answer these for the system you work on.
Go deeper
- System Design Primer (opens in a new tab) · GitHub (donnemartin)