Back-of-Envelope Estimation: Capacity Planning for System Design

The goal

Not precision — order-of-magnitude correctness. Whether your read QPS is 8K or 12K doesn't matter; whether it's 10K or 10M does. The right order of magnitude tells you single DB or sharded, cache or no cache, single region or global, sync or queue.

The four dimensions, always cover all four

1. 1
   Traffic: DAU × actions/user ÷ 86,400 = avg QPS; × 3-5 for peak; split read vs write
2. 2
   Storage: items × size × users × replication factor × growth projection
3. 3
   Bandwidth: QPS × response size = network egress; cross-region replication adds 25%
4. 4
   Memory: hot working set (Pareto: 20% of data = 80% of traffic) × 1.3 overhead

Numbers to memorize

Latency: L1=1ns, RAM=100ns, SSD=100μs, RTT same DC=500μs, cross-continent=100ms.

Sizes: URL=50B, tweet=1KB, image=100KB, doc=1MB, video minute=10MB.

Anchors: server=10K QPS, Redis=100K ops/sec, Postgres=10K writes/sec, Kafka partition=10MB/sec, 1Gbps=125MB/sec.

Worked example — Twitter-like, 200M DAU, 2 tweets, 100 reads per user

• Writes: 200M × 2 / 86,400 = 4,600/sec avg, 15K peak
• Reads: 200M × 100 / 86,400 = 230K/sec avg, 700K peak
• Read:write = 50:1 → read-optimized architecture
• Storage: 400M tweets/day × 50KB ≈ 20 TB/day; 5y × 3 replicas ≈ 110 PB
• Bandwidth: 230K reads × 50KB = 12 GB/sec read; 700 MB/sec write
• Cache: top 20% of recent tweets ≈ 560 GB Redis cluster

Convert to architecture

• Sharded write store (Cassandra, ~30 shards at 50K writes/sec each)
• Read tier with regional cache + CDN for media
• Object storage for media, not relational DB
• Multi-region active-active reads, primary region writes

From estimate to server count — Little's Law

servers = peak QPS × avg latency / target utilization

Example: 100K QPS × 10ms = 1000 concurrent. 100 per server = 10 minimum. /0.7 utilization = 15. ×3 AZs = 45 servers.

Peak vs average — the most common mistake

• Diurnal peaks ~3x average
• Event spikes 10x
• Flash sales 100x
• Always design for peak, capacity at 50% utilization to absorb AZ failure + deploy + spikes

Common mistakes

• Quoting average without peak
• Forgetting read:write ratio (drives entire architecture)
• Underestimating growth (5 years at 2x/year = 32x)
• Ignoring metadata overhead (3-5x raw payload on disk)
• Assuming linear scaling (hot keys, lock contention break it)
• Not converting numbers into architecture decisions
• Skipping bandwidth (100 GB/sec needs CDN, period)

Recommendation

Always start with DAU and derive QPS/storage/bandwidth/memory in that order. Memorize the latency, size, and capacity anchors. Multiply average by 3-10x for peak. Use Little's Law to convert QPS-into-server-count. Most importantly, convert every estimate into an architectural decision — numbers without an architecture conclusion are wasted breath.