Capacity Estimation

Difficulty: Intermediate

Question

How do you estimate the capacity requirements for a system? Walk through a back-of-the-envelope calculation for a social media platform.

Answer

Capacity estimation (back-of-the-envelope calculation) is a critical skill in system design interviews. It helps you make informed architecture decisions.

Key numbers to estimate: 1. QPS (Queries Per Second): How many requests the system handles 2. Storage: How much data is stored and grows over time 3. Bandwidth: How much data flows in and out per second 4. Memory: How much cache is needed

Approach: 1. Start with user counts and activity patterns 2. Calculate daily active users (DAU) from monthly active users (MAU) 3. Estimate reads vs writes ratio 4. Calculate peak QPS (usually 2-3x average) 5. Estimate storage per entity and growth rate

Useful reference numbers: - 1 day = 86,400 seconds (round to 100K for estimation) - 1 million requests/day = ~12 QPS - 1 billion requests/day = ~12,000 QPS

Code examples

Twitter-Scale Capacity Estimation

// Twitter-like social media platform estimation

// Step 1: User metrics
// Total users: 500 million
// DAU: 200 million (40% of total)
// Average tweets per user per day: 2
// Average reads per user per day: 100 (timeline views)

// Step 2: QPS calculations
// Write QPS: 200M users * 2 tweets / 86400 sec = ~4,600 QPS
// Peak write QPS: 4,600 * 3 = ~14,000 QPS
// Read QPS: 200M * 100 / 86400 = ~230,000 QPS
// Peak read QPS: 230,000 * 3 = ~700,000 QPS
// Read:Write ratio = 230K/4.6K = 50:1 (read-heavy!)

// Step 3: Storage estimation
// Tweet: id(8B) + userId(8B) + text(280B) + metadata(100B) = ~400B
// Media: 20% of tweets have images, avg 200KB
// Daily tweets: 200M * 2 = 400M tweets
// Daily text storage: 400M * 400B = 160GB/day
// Daily media storage: 400M * 0.2 * 200KB = 16TB/day
// Yearly text: 160GB * 365 = 58TB/year
// Yearly media: 16TB * 365 = 5.8PB/year

// Step 4: Bandwidth
// Incoming (writes): 400M tweets * 400B / 86400 = ~1.8 MB/s (text)
//   + media: 80M images * 200KB / 86400 = ~185 MB/s
// Outgoing (reads): 50x write traffic
//   Text: 1.8 MB/s * 50 = ~90 MB/s
//   Media: 185 MB/s * 50 = ~9.3 GB/s (CDN handles this)

// Step 5: Memory/Cache estimation
// Cache the 20% most popular tweets (Pareto principle)
// Hot tweets: 400M * 0.2 = 80M tweets
// Cache size: 80M * 400B = 32GB (fits in a single Redis instance!)
// Timeline cache: 200M users * 20 tweets * 8B (tweet IDs) = 32GB

Start with user counts, calculate QPS from daily activity, then estimate storage, bandwidth, and cache needs. Always calculate peak values (3x average) for provisioning.

Latency Numbers Every Programmer Should Know

// Latency reference numbers (approximate, 2025)

// Memory & CPU
// L1 cache reference:               0.5 ns
// L2 cache reference:               7 ns
// Main memory reference:             100 ns
// Mutex lock/unlock:                 25 ns

// Storage
// SSD random read:                   150 us (microseconds)
// SSD sequential read (1MB):         1 ms
// HDD seek:                          10 ms
// HDD sequential read (1MB):         20 ms

// Network
// Same datacenter round trip:        0.5 ms
// Send 1MB over 1 Gbps network:     10 ms
// Cross-continent round trip:        150 ms

// Operations
// Compress 1KB with Snappy:          3 us
// Read 1MB from memory:              250 us
// Redis GET:                         0.1-0.5 ms
// PostgreSQL simple query:           1-5 ms
// PostgreSQL complex query:          10-100 ms

// Key takeaways:
// 1. Memory is 100,000x faster than disk
// 2. SSD is 100x faster than HDD
// 3. Network within datacenter is fast (0.5ms)
// 4. Cross-continent adds 150ms latency
// 5. Redis < 1ms, Postgres 1-100ms, external API 50-500ms

// Practical implications:
// - Cache in memory when possible (Redis/Memcached)
// - Use SSD for databases
// - Keep services in the same datacenter/region
// - Minimize cross-continent calls
// - Batch operations to amortize network latency

These numbers help you estimate whether your design will meet latency requirements. Memory operations are nanoseconds, disk is microseconds to milliseconds, network is milliseconds.

Estimation Shortcuts & Powers of 2

// Powers of 2 for quick estimation
// 2^10 = 1 KB   (1,024)
// 2^20 = 1 MB   (1,048,576)
// 2^30 = 1 GB   (1,073,741,824)
// 2^40 = 1 TB
// 2^50 = 1 PB

// Time conversions
// 1 second                    = 1
// 1 minute                    = 60
// 1 hour                      = 3,600
// 1 day                       = 86,400 (~10^5)
// 1 month                     = 2.6M (~2.5 * 10^6)
// 1 year                      = 31.5M (~3 * 10^7)

// Quick QPS conversion
// 1M requests/day  = ~12 QPS
// 10M requests/day = ~120 QPS
// 100M requests/day = ~1,200 QPS
// 1B requests/day  = ~12,000 QPS

// Common data sizes
// Character (ASCII): 1 byte
// Character (UTF-8): 1-4 bytes
// Integer: 4-8 bytes
// UUID: 16 bytes (128 bits)
// Timestamp: 8 bytes
// URL: ~100 bytes
// Email: ~50 bytes
// Tweet (280 chars): ~300 bytes with metadata
// Image (compressed): 100KB - 2MB
// Video (1 min, compressed): 10MB - 50MB

// Estimation example: "How much storage for 1B messages/day?"
// Average message: 200 bytes text + 50 bytes metadata = 250 bytes
// Daily: 1B * 250B = 250GB/day
// Monthly: 250GB * 30 = 7.5TB/month
// Yearly: 7.5TB * 12 = 90TB/year
// With 3x replication: 270TB/year
// With 20% media: add 1B * 0.2 * 200KB = 40TB/day for media

Memorize powers of 2 and time conversions for fast estimation. Round aggressively to keep math simple. Always account for replication and growth when sizing storage.

Key points

Concepts covered

Back-of-Envelope, QPS, Bandwidth, Storage, Latency Numbers