Capacity Planning and Back-of-the-envelope Estimation
Use rough maths up front to estimate how many QPS, how much storage, how much bandwidth and how many servers you will need.
50.1 Why is it used?
- Without an estimate you either have too few servers (a crash on sale day) or far too many (wasted money).
- It is the first step in a system design interview: how big is the scale, and design accordingly (will a single DB do or is sharding needed).
- Budget and cloud bill are planned in advance, and you can buy reserved instances/savings plans correctly.
- Understanding the peak factor lets you set autoscaling limits, DB size and CDN capacity in advance.
50.2 How it works
- Numbers to remember: 1 day = 86,400 sec (round it to ~1 lakh), 1 million req/day = ~12 QPS, 1 billion req/day = ~12K QPS.
- QPS formula: Avg QPS = DAU x requests per user per day / 86,400; Peak QPS = Avg QPS x peak factor (normal 2-3x, sale 10-20x).
- Storage formula: records per day x size per record x retention days x replication factor (usually 3).
- Bandwidth formula: Peak QPS x average response size; multiply bytes/sec by 8 to get bits/sec (Gbps).
- Servers: Peak QPS / capacity of one server (from a load test) x headroom (1.3-1.5x) + N+1 or a buffer for one AZ failing.
- Work out the read:write ratio (about 100:1 read heavy in e-commerce); it drives the cache and read replica decisions.
- Units: 1 KB = 10^3, 1 MB = 10^6, 1 GB = 10^9, 1 TB = 10^12 bytes; use round numbers in interviews.
- Latency numbers: memory read ~100 ns, SSD read ~100 us, same-DC round trip ~0.5 ms, India-US round trip ~200 ms.
- 1.A QPS (normal day): 100M DAU x 20 req/user = 2 billion req/day; / ~1 lakh (86,400) = ~23K avg QPS; x3 peak = ~70K QPS
- 2.B Servers (sale day): 10 lakh QPS / 1,000 RPS per pod (load test) = 1,000 pods; x1.4 (40% headroom + AZ buffer) = ~1,400 pods, pre-scale them
- 3.C Storage: 10M orders/day x 2 KB = 20 GB/day; x365 = 7.3 TB; x3 replication = ~22 TB; images 10 cr x 5 x 300 KB = 150 TB (S3 + CDN); cache 2 crore hot products x 10 KB = 200 GB Redis
- 4.D Bandwidth: 70K QPS x 100 KB = 7 GB/s; x8 = 56 Gbps; the CDN serves 80-90%, origin 6-10 Gbps
- 5.Decision: DB sharding, CDN a must, Redis cache, pre-scaling 2 weeks ahead
The top 20% of products bring 80% of traffic; read:write = 100:1. Tools: spreadsheet scenarios, validate the last peak with Grafana/CloudWatch, per-pod RPS from k6/JMeter, the bill from AWS Pricing Calculator.
50.3 Tools
| Tool | Type | How it is used |
|---|---|---|
| Spreadsheet (Excel / Google Sheets) | Estimation calculator | Keep DAU, req/user, peak factor and size as inputs and compute QPS, storage, servers and cost with formulas; use tabs for scenarios. |
| Grafana + Prometheus | Metrics & dashboards | Look at trends of real QPS, CPU and p99 latency to get growth and the last peak's data. |
| AWS CloudWatch | AWS metrics & alarms | Build a capacity baseline from historic graphs of ALB RequestCount, EC2/RDS CPU and network bytes. |
| AWS Pricing Calculator | Cost estimator | Enter estimated EC2, RDS, S3 and data transfer to get the monthly bill; Azure/GCP have their own calculators too. |
| AWS Compute Optimizer / Trusted Advisor | Rightsizing advisor | Shows which instances are over/under-provisioned and gives recommendations based on usage. |
| Load testing tools (k6, JMeter) | Capacity measurement | Measure the real max RPS of one server/pod, which feeds the server count formula. |
50.4 Comparison: Amazon-like site: Normal day vs Sale day vs IPL-final-like spike (assumed numbers)
| Point | Normal day | Sale day (Big Billion / Prime Day type) | IPL-final-like spike |
|---|---|---|---|
| Users | 100M DAU | ~3x users, 300M DAU | Crores of concurrent viewers at the same time |
| Avg QPS | 100M x 20 req / 86,400 = ~23K QPS | 300M x 30 req / 86,400 = ~1 lakh QPS | The average matters little, concurrency matters |
| Peak factor | 2-3x, peak ~60-70K QPS | 10x+ at sale start, peak ~10 lakh QPS | 5-10x jump within seconds (toss, last over, wicket) |
| Traffic shape | Smooth, peaks in the evening | A sudden wall at 12 midnight, then slowly falls | Sharp spikes with the live event, video bandwidth dominates |
| Bandwidth | 70K QPS x 100 KB = ~7 GB/s = ~56 Gbps (mostly CDN) | 10 lakh x 100 KB = ~100 GB/s = ~800 Gbps, CDN a must | 1 crore viewers x 2 Mbps = ~20 Tbps, possible only with a CDN |
| Write load | 10M orders/day = ~115 writes/sec avg | ~1 crore orders in a few hours, ~2-5K orders/sec peak | Few writes, mostly reads/streaming; comments, score updates |
| Planning style | Autoscaling + 30% headroom | Pre-scale weeks ahead, load test at 2x peak, queue/waiting room | Pre-warm the CDN, pre-scale, graceful degradation of non-critical features |
50.5 When to choose which
- In an interview: state assumptions first (DAU, req/user, size), then work out QPS, storage, bandwidth and servers in round numbers; the logic matters more than exactness.
- Spreadsheet: for real planning, with separate normal/sale/spike scenarios side by side.
- Grafana/CloudWatch: to validate assumptions against last year's real peak data.
- AWS Pricing Calculator: when you must show the estimate to finance in rupees/dollars.
- Load test: never guess per-server capacity, measure it.
50.6 Real-world example
Worked numbers: estimating an Amazon-like site (assumed numbers).
- Assumption: 100M DAU, each user makes 20 requests a day (browse, search, cart), read:write = 100:1.
- Avg QPS = 100M x 20 / 86,400 = 2 billion / ~1 lakh = ~23K QPS; peak factor 3 -> ~70K QPS normal peak.
- Sale day: assume a peak of 10 lakh QPS; if one app pod handles 1,000 RPS (from a load test) that is 1,000 pods + 40% headroom = ~1,400 pods.
- Storage (orders): 10M orders/day x 2 KB = 20 GB/day; 1 year = ~7.3 TB; 3x replication = ~22 TB.
- Storage (images): 10 crore products x 5 images x 300 KB = 150 TB, keep it in S3 and serve it through a CDN.
- Bandwidth: 70K QPS x 100 KB = 7 GB/s = 56 Gbps; 80-90% of it (images/static) goes through the CDN, leaving ~6-10 Gbps on the origin.
- Cache: the top 20% of products bring 80% of traffic; 2 crore hot products x 10 KB = a 200 GB Redis cluster.
- This maths decided it: DB sharding is needed, a CDN is a must, a Redis cache, and pre-scaling 2 weeks before the sale.
50.7 Interview tips
- Do not waste time on exact calculation; round 86,400 to 10^5 and state your assumptions loudly.
- Common mistake: designing only for average QPS and forgetting the peak factor; a sale-day peak can be 10-20x the average.
- Forgetting to add replication factor, indexes and backups to storage; real storage comes out 3-5x. Mixing bytes and bits (MB/s vs Mbps, a factor of 8) is also common.
- Numbers to remember: 1 million req/day = ~12 QPS, 1 billion req/day = ~12K QPS, peak factor 2-3x normally and 10-20x on sale days.