📐 Back-of-envelope system design estimation
QPS & capacity calculator
The back-of-envelope estimation every system design interview starts with. Give it monthly active users, average requests per user and average payload size — it derives an average/peak/P99 traffic profile, a breakdown of QPS across the stack (API, cache, database, internal fan-out), bandwidth, storage (with replication), cache size and server count. Every assumption (DAU/MAU ratio, peak multiplier, cache hit ratio, fan-out factor, replication factor, growth rate…) is editable, so you can show your reasoning, not just a number.
Traffic profile
DAU
200.00K
1.00M MAU × 20% = 200.00K
Total requests / day
2.00M
200.00K DAU × 10 req/user = 2.00M
Average QPS
23
2.00M ÷ 86,400s = 23
Peak QPS
69
23 avg × 3 = 69
P99 burst QPS
104
69 peak × 1.5 = 104
size headroom to this, not the average
Read QPS (peak)
63
69 peak × 90% = 63
Write QPS (peak)
6.94
69 peak × 10% = 6.94
Backend breakdown (at peak)
External API QPS
69
= peak QPS above
what the front door sees
Cache-served QPS
50
63 reads × 80% hit ratio = 50
DB read QPS
13
63 reads − 50 cached = 13
DB write QPS
6.94
= write QPS above (all writes hit the DB)
Total DB QPS
19
13 reads + 6.94 writes = 19
what the database tier must sustain
Internal / fan-out QPS
208
69 external × 3 fan-out = 208
service-to-service + DB calls; QPS isn't just HTTP requests
Bandwidth (at peak)
Read bandwidth
512.00 Kbps
63 req/s × 1.00 KB = 512.00 Kbps
Write bandwidth
56.89 Kbps
6.94 req/s × 1.00 KB = 56.89 Kbps
Total bandwidth
682.67 Kbps
(512.00 Kbps + 56.89 Kbps) × 1.2 = 682.67 Kbps
incl. +20% protocol/header overhead
Storage
Writes / day
195.31 MB
2.00M req/day × 10% writes × 1.00 KB = 195.31 MB
Storage / year
69.62 GB
195.31 MB × 365 = 69.62 GB
Total over 5y (raw)
348.09 GB
69.62 GB × 5y = 348.09 GB
Total over 5y (replicated)
1.02 TB
348.09 GB × 3 replicas = 1.02 TB
Cache & servers
Cache size
13.92 GB
69.62 GB × 20% = 13.92 GB
Pareto rule — hot share of a year's data
Cache nodes needed
1.00
13.92 GB ÷ 64 GB/node = 1
App servers needed
1.00
(69 ÷ 1500) × 1.30 buffer = 1
Growth projection
At 20% YoY MAU growth. “Storage / year” is data generated in that year alone, not a running total.
| Year | MAU | Avg QPS | Peak QPS | Storage / year |
|---|---|---|---|---|
| Today | 1.00M | 23 | 69 | 69.62 GB |
| +1y | 1.20M | 28 | 83 | 83.54 GB |
| +3y | 1.73M | 40 | 120 | 120.30 GB |
| +5y | 2.49M | 58 | 173 | 173.23 GB |
The back-of-envelope method
Capacity estimation converts a product-level number (how many people use this) into engineering numbers (how many servers, how much storage, how much bandwidth). The chain is always the same: MAU → DAU (via a stickiness ratio) → total daily requests → average QPS → peak QPS (via a peak multiplier), then peak QPS and total request volume feed bandwidth, storage and cache sizing. None of this needs to be exact — the point is a defensible order-of-magnitude estimate with explicit assumptions.
A few rules of thumb worth memorizing: peak traffic is usually 2-3× average; storage is typically provisioned with a 3x replication factor for durability; a cache sized at the top ~20% of data (the Pareto principle) usually serves ~80% of read traffic; and a single web server commonly sustains 1,000-2,000 QPS before you need to scale horizontally.
One number isn't enough, though. QPS isn't just HTTP requests — it covers frontend API calls, microservice-to-microservice traffic, database reads/writes, cache lookups and background jobs, and each tier needs its own QPS figure. This calculator profiles traffic at average, peak and P99 (rather than a single number) and breaks total request volume down into API, cache-served, database and internal fan-out QPS, since those are the numbers that actually size the load balancer, the cache cluster, the database replicas and the service mesh respectively.
Latency numbers to memorize
| Operation | Typical latency |
|---|---|
| L1 cache reference | ~0.5 ns |
| Main memory (RAM) reference | ~100 ns |
| Round trip within same data center | ~0.5 ms |
| Cross-region (within the US) | ~40-50 ms |
| Transatlantic round trip | ~100-150 ms |
Common data sizes
| Data type | Typical size |
|---|---|
| Integer / Long | 4-8 bytes |
| UUID | 16 bytes |
| Average URL | ~100 bytes |
| Short text message (tweet-sized) | ~300 bytes |
| Average compressed image | 200 KB - 2 MB |
Common questions
- What is QPS in system design?
- QPS (queries per second) is the rate of requests a system must handle. "Average QPS" is total daily requests divided by 86,400 seconds; "peak QPS" multiplies that by a peak factor (usually 2-3x) to size for busy periods rather than the daily average.
- How do I go from MAU to QPS?
- MAU (monthly active users) → DAU (daily active users) using a stickiness ratio (10-20% for most consumer apps, 50%+ for very sticky/social apps) → total daily requests (DAU × requests per user per day) → average QPS (÷ 86,400) → peak QPS (× peak multiplier).
- Why multiply storage by a replication factor?
- Distributed databases keep multiple copies of data for durability and availability — 3x replication is the standard rule of thumb (e.g. 3 replicas in different availability zones). Raw storage is the actual data volume; replicated storage is what you provision.
- Why is cache sized at only ~20% of the data?
- Real-world access patterns follow the Pareto principle: roughly 20% of the data (the recent/popular subset) serves about 80% of read traffic. Caching that "hot" slice gets most of the read-latency benefit without paying to cache everything.
- What is a good default for requests per user per day?
- It depends entirely on the product — a messaging or social feed app might see 20-50+ requests/user/day (every scroll, poll, or send is a request), while a low-frequency utility might see 1-5. State your assumption explicitly in an interview and justify it from the product's usage pattern.
- Is QPS just the number of HTTP requests?
- No — that's only the "external API" tier. Every incoming request can fan out into several internal calls: other microservices, the database, the cache. A system handling 1,000 external QPS might generate several thousand QPS internally once you count service-to-service and database traffic — which is the number that actually determines how many backend instances and DB replicas you need.
- What is the difference between API QPS and database QPS?
- API (or "front-door") QPS is what load balancers and web servers see. Database QPS is smaller once a cache is in front of it — a healthy cache hit ratio (commonly 70-90% for read-heavy systems) absorbs most reads, so only cache misses plus all writes reach the database. Sizing the DB tier off raw API QPS instead of post-cache QPS massively over-provisions it.
- Why look at P99, not just average or peak?
- Averages hide bursts, and even a single "peak" multiplier is still a smoothed estimate. Production traffic is better described by percentiles: P95/P99 QPS captures the rare spikes (a viral post, a marketing push, a retry storm) that actually cause outages. Capacity planning should headroom to P99, not to the average.