Capacity Planning
Estimate QPS, storage, bandwidth, and infrastructure for any system. Select a preset or enter custom values.
Read-heavy. Users tweet ~5 times/day but read feeds constantly.
Input Parameters
100:1 (reads per write)
3x average
How to Use in Interviews
- Start with DAU — Ask the interviewer for scale. If they say "design for 100M users", that's your DAU.
- Estimate actions per user — How many writes per user per day? Twitter: ~5 tweets. WhatsApp: ~100 messages.
- Determine read:write ratio — This decides your architecture. High reads → caching. High writes → write-optimized DB.
- Calculate QPS — DAU × actions ÷ 86,400. Multiply by peak factor for capacity planning.
- Estimate storage — Items/day × bytes per item × retention period. This tells you if you need sharding.
- Use results to justify decisions — "Since peak QPS is 50K, a single DB won't handle it, so we need read replicas or sharding."
Queries Per Second (QPS)
Write QPS (avg)
17.4K
Write QPS (peak)
52.1K
Read QPS (avg)
1.7M
Read QPS (peak)
5.2M
Total QPS (avg)
1.8M
Total QPS (peak)
5.3M
⚡ High read QPS — you'll need caching (Redis/Memcached) and possibly read replicas.
Storage
Per Day
750.00 GB
Per Year
273.75 TB
Total (5yr)
1.37 PB
Cache Memory (20%)
273.75 TB
⚡ Petabyte-scale storage — need distributed storage (HDFS, S3) with careful partitioning.
Bandwidth
Inbound (avg)
71.11 Mbps
Inbound (peak)
213.33 Mbps
Outbound (avg)
28.44 Gbps
Outbound (peak)
85.33 Gbps
Infrastructure Estimate
App Servers
~527
@ 10K QPS each
DB Instances
~1053
@ 5K QPS each
Cache Nodes
~53
@ 100K QPS each
These are rough estimates. Real capacity depends on query complexity, data model, and hardware specs. Always add 30-50% headroom.
Quick Reference Numbers
Seconds/Day
86,400
≈ 10⁵ for quick math
Seconds/Month
2,592,000
≈ 2.5 × 10⁶
1 Server Handles
10K-50K QPS
depends on workload
Redis Throughput
100K+ QPS
single instance
Kafka Throughput
1M+ msg/sec
per cluster
SSD Random Read
100 μs
0.1 ms
Network RTT
0.5 ms
same datacenter
Cross-Region RTT
~150 ms
US East → EU