Capacity Estimation for System Design Interviews
A practical guide to estimating QPS, storage, bandwidth, memory, and peak traffic in system design interviews without getting lost in math.
Estimate only what changes the design
Capacity estimation is not a math quiz. The interviewer wants to see that you can turn product usage into engineering constraints. Estimate the numbers that affect architecture: QPS, writes per second, storage growth, bandwidth, cache size, and queue depth.
If a number does not influence a choice, skip it or keep it brief.
Use a consistent flow
Start with users and actions. Convert daily activity into average QPS, apply a peak multiplier, multiply by payload size for bandwidth, and multiply by retention period for storage. Round aggressively. A defensible estimate is better than fake precision.
- DAU x actions per user per day = daily requests.
- Daily requests / 86,400 = average QPS.
- Average QPS x peak multiplier = peak QPS.
- Writes x payload size x retention = storage growth.
Connect numbers to bottlenecks
The useful sentence comes after the estimate: "At this write rate, one primary database is risky," or "This cache needs roughly 40 GB, which fits in a small Redis cluster," or "The queue can absorb a five-minute provider outage if we provision this many workers."
That connection is what separates senior estimation from arithmetic.