Blog
Back-of-the-Envelope Estimation for System Design Interviews
March 4, 2026 · Updated March 4, 2026 · 10 min read
A step-by-step framework for capacity estimation: QPS, storage, bandwidth, and memory calculations that interviewers actually expect.
Definition
Back-of-the-envelope estimation is a quick, approximate calculation technique used in system design interviews to size infrastructure: compute, storage, bandwidth, and memory requirements from user and traffic assumptions.
Implementation Checklist
- Start with user count and activity assumptions, then derive QPS from daily active users and actions per user.
- Estimate storage by multiplying object size by write volume over the retention period.
- Calculate bandwidth from QPS multiplied by average response size for both read and write paths.
- Size memory by identifying the hot working set and applying the 80/20 rule to total data volume.
- State your assumptions explicitly and round to powers of 10 for speed.
The Four Estimates That Matter
Every system design estimation boils down to four numbers: QPS (how many requests per second), storage (how much data over the retention window), bandwidth (how much data flows per second), and memory (how much hot data fits in cache).
Start with users and actions. 10 million DAU doing 5 actions each is 50 million actions per day, which is about 600 QPS average and 1,200-1,800 QPS at peak.
Worked Example: URL Shortener
Assume 100 million URLs created per month, 10:1 read-to-write ratio. Writes: 100M / 30 / 86400 is about 40 QPS. Reads: 400 QPS. Each URL record is about 500 bytes. Monthly storage: 100M x 500B = 50 GB. Over 5 years: 3 TB.
Cache sizing: if 20% of URLs get 80% of reads, cache 20% of 3 TB = 600 GB. This fits in a distributed Redis cluster. These numbers tell you the system needs modest compute but meaningful storage and cache layers.
Common Mistakes in Estimation
Forgetting to separate read and write QPS leads to wrong scaling decisions. Ignoring peak-to-average ratios under-provisions burst capacity. Not stating retention period makes storage estimates meaningless.
Always say your assumptions out loud. The interviewer cannot grade reasoning they cannot hear.
Tradeoff Table
| Decision | Speed-First Option | Reliability-First Option | Recommended When |
|---|---|---|---|
| Precise calculation vs Quick approximation | Quick powers-of-10 rounding keeps the interview moving and shows structured thinking. | Precise calculation catches order-of-magnitude errors that change architecture decisions. | Use quick approximation in interviews. Save precise math for production capacity planning. |
| Optimistic vs Pessimistic assumptions | Optimistic assumptions keep infrastructure lean and reduce initial cost. | Pessimistic assumptions build headroom for traffic spikes and growth. | Design for 2-3x expected peak. State the multiplier explicitly so the interviewer sees your reasoning. |
| Single-number estimate vs Range estimate | A single number is faster to communicate and easier to reason about. | A range shows awareness of uncertainty and makes assumptions auditable. | Give a single number with an explicit assumption list. Mention the range only when the interviewer probes. |
Practice Next
Databases Topic Hub
Storage, scaling, and data modeling patterns for system design.
Capacity Estimation Drill
Practice back-of-the-envelope math with guided prompts and worked solutions.
Challenges
- Easy URL Shortener
Apply capacity estimation to size a URL shortener for millions of users.
- Design Twitter
Estimate QPS, storage, and fanout costs for a social media timeline system.
Newsletter CTA
Join the SystemForces newsletter for practical estimation frameworks and architecture notes.
Get weekly system design breakdownsFrequently Asked Questions
What numbers should I memorize for system design interviews?
Know these: 1 day is 86,400 seconds (round to 100K). 1 million requests per day is about 12 QPS. SSD reads are about 100 microseconds. Network round-trip within a datacenter is about 0.5ms. 1 TB is 1 trillion bytes.
How accurate do my estimates need to be?
Within an order of magnitude is fine. The interviewer cares about your reasoning process, explicit assumptions, and whether the final number changes your architecture decision.
When should I do capacity estimation in an interview?
Do it after clarifying requirements and before diving into component design. Estimation informs whether you need sharding, caching, or async processing.