Chapter 79: Capacity Estimation Cheat Sheet

This is your interview lifeline. Memorize these numbers. When the interviewer says "Design YouTube," you need to estimate QPS, storage, and bandwidth in under 5 minutes. This chapter gives you every formula, constant, and shortcut you need.

Powers of 2 (Memory Sizes)

Critical for storage and memory calculations. Round to nearest power of 10 for estimation.

Power Exact Value Approx Name Short
2^10 1,024 ~1 thousand Kilobyte 1 KB
2^20 1,048,576 ~1 million Megabyte 1 MB
2^30 1,073,741,824 ~1 billion Gigabyte 1 GB
2^40 1,099,511,627,776 ~1 trillion Terabyte 1 TB
2^50 1,125,899,906,842,624 ~1 quadrillion Petabyte 1 PB
Interview Hack: Use powers of 10 for estimation, not powers of 2.
1 KB = 1,000 bytes (not 1,024)
1 MB = 1,000,000 bytes (not 1,048,576)
This simplifies math without meaningful loss of accuracy.

Time Constants

You'll use these in every capacity calculation. Memorize them.

Duration Seconds Shortcut
1 minute 60 -
1 hour 3,600 ~4K
1 day 86,400 ~100K
1 week 604,800 ~600K
1 month (30 days) 2,592,000 ~2.5M
1 year (365 days) 31,536,000 ~30M
Key Formula:
QPS = Total Daily Requests / 86,400
Peak QPS = Average QPS × 2 to 3

Quick Conversion:
1M requests/day = 1,000,000 / 86,400 ≈ 12 requests/sec

Common Data Sizes

Typical sizes for objects you'll encounter in system design interviews.

Object Type Size Notes
Tweet (text only) 280 bytes 280 chars (1 byte/char for ASCII)
Tweet with metadata 500 bytes Includes user_id, timestamp, IDs
User record 1 KB Username, email, profile fields
Small image (thumbnail) 100 KB Compressed JPEG, 200×200px
Photo (high quality) 2-5 MB Compressed JPEG, 4000×3000px
1-minute video (SD) 10-20 MB H.264, 480p
1-minute video (HD) 50-100 MB H.264, 1080p
Web page (HTML + assets) 1-3 MB Modern single-page app
JSON API response 1-10 KB Typical REST endpoint
Log entry 200 bytes Timestamp, level, message
Interview Tip: If you don't know the exact size, state an assumption. "Let's assume a tweet is 500 bytes including metadata." The interviewer cares about your reasoning, not memorizing exact numbers.

Server Capacities

How much load can one server handle? These are ballpark numbers for modern hardware.

Server Type QPS (Throughput) Notes
Web Server (static content) 10,000 - 50,000 Nginx, simple GET requests
Application Server (API) 1,000 - 5,000 Stateless REST API, lightweight logic
Application Server (heavy logic) 100 - 500 Complex business logic, external calls
Database (SQL, simple query) 1,000 - 5,000 Indexed SELECT, small result set
Database (SQL, complex query) 100 - 500 Joins, aggregations
NoSQL (key-value lookup) 10,000 - 100,000 Redis, Memcached (in-memory)
NoSQL (disk-based) 5,000 - 50,000 Cassandra, DynamoDB
Server Count Formula:
Number of Servers = Peak QPS / QPS per Server

Example: 100K QPS, API server handles 2K QPS
→ Need 100K / 2K = 50 API servers
→ Add 20% buffer for failover = 60 servers

Database Numbers

Critical limits for relational and NoSQL databases.

Metric Value Context
Max connections (PostgreSQL) ~100-300 Default config, can increase but expensive
Max connections (MySQL) ~150 Default, configurable but limited by RAM
IOPS (SSD) 10,000 - 100,000 Cloud SSD (AWS gp3, Azure Premium)
IOPS (HDD) 100 - 200 Spinning disk, avoid for high QPS
Storage per server 1-16 TB Single disk, shard beyond this
Max table size (practical) ~1-2 TB Beyond this, consider partitioning
Index size overhead 10-30% of data B-tree index on table
Replication lag (same region) 1-10 ms Async replication
Replication lag (cross-region) 50-200 ms Geographic distance

Network Numbers

Bandwidth and latency constraints.

Metric Value Notes
Bandwidth (1 Gbps NIC) 125 MB/sec Theoretical max (1 Gbit / 8)
Bandwidth (10 Gbps NIC) 1.25 GB/sec Modern server
Internet bandwidth (user) 10-100 Mbps Home broadband
Mobile bandwidth (4G) 5-50 Mbps Real-world speeds
Round-trip latency (same datacenter) < 1 ms Sub-millisecond
Round-trip latency (same region) 1-5 ms Within 100km
Round-trip latency (cross-region, US) 20-50 ms East Coast to West Coast
Round-trip latency (cross-continent) 100-300 ms US to Europe or Asia
DNS lookup 10-100 ms Can be cached
TLS handshake 50-200 ms 1-2 RTTs + computation
Bandwidth Formula:
Bandwidth (bytes/sec) = QPS × Average Response Size

Example: 10K QPS, 5KB response
→ 10,000 × 5,000 = 50 MB/sec
→ Needs 400 Mbps (50 × 8)

QPS Formula

Convert daily active users to queries per second.

Step-by-Step QPS Calculation
GIVEN:
- DAU = Daily Active Users
- Actions = Actions per user per day

STEP 1: Total Daily Requests
Total = DAU × Actions

STEP 2: Average QPS
Average QPS = Total / 86,400

STEP 3: Peak QPS (account for traffic spikes)
Peak QPS = Average QPS × Peak Factor

Peak Factor:
- Light usage (enterprise apps): 1.5x
- Moderate usage (social media): 2x
- Heavy spikes (live events, flash sales): 3-5x

Example: Instagram

Given: Calculation: 
READ:
- Total reads = 500M × 50 = 25B reads/day
- Average read QPS = 25B / 86,400 ≈ 289,000 QPS
- Peak read QPS = 289K × 2 = 578,000 QPS

WRITE:
- Total writes = 500M × 1 = 500M writes/day
- Average write QPS = 500M / 86,400 ≈ 5,800 QPS
- Peak write QPS = 5,800 × 2 = 11,600 QPS

Storage Formula

Estimate long-term storage needs.

Storage Calculation
FORMULA:
Storage = Object Size × Daily Objects × Retention Days × Replication Factor

STEP 1: Daily Storage
Daily = Object Size × Daily Objects

STEP 2: Total Storage (with retention)
Total = Daily × Retention Days

STEP 3: With Replication
Final = Total × Replication Factor

Typical Replication Factors:
- 3x for HDFS, Cassandra (3 replicas)
- 1.5x for S3 (erasure coding, 1.5x overhead)
- 2x for MySQL (primary + replica)

Example: YouTube

Given: Calculation: 
DAILY UPLOADS:
- 500 hours/min × 60 min/hour × 24 hours = 720,000 hours/day

DAILY STORAGE:
- 720,000 hours × 6 GB/hour (1GB per 10min) = 4,320,000 GB/day
- = 4,320 TB/day = 4.3 PB/day

10 YEAR STORAGE:
- 4.3 PB/day × 365 × 10 = 15,695 PB ≈ 16 Exabytes

WITH REPLICATION (3x):
- 16 EB × 3 = 48 Exabytes

Bandwidth Formula

Calculate ingress and egress bandwidth.

Bandwidth Calculation
INGRESS (Upload):
Ingress = Write QPS × Average Object Size

EGRESS (Download):
Egress = Read QPS × Average Object Size

EXAMPLE (Instagram):
- Write QPS = 11,600
- Read QPS = 578,000
- Photo size = 2 MB

Ingress:
11,600 × 2 MB = 23,200 MB/sec ≈ 23 GB/sec

Egress:
578,000 × 2 MB = 1,156,000 MB/sec ≈ 1,156 GB/sec ≈ 1.1 TB/sec
Reality Check: 1.1 TB/sec is 9 Terabits/sec. This requires massive CDN infrastructure. Instagram serves most reads from CDN cache, so actual origin egress is ~1-10% of this. Always mention CDN for media-heavy apps.

Worked Examples

Example 1: Design TinyURL

Requirements: QPS: 
WRITE:
- 100M URLs/month = 100M / 2.5M sec ≈ 40 writes/sec
- Peak = 40 × 2 = 80 writes/sec

READ:
- 100M × 100 = 10B reads/month
- Average = 10B / 2.5M ≈ 4,000 reads/sec
- Peak = 8,000 reads/sec
Storage (10 years): 
- URL entry = 500 bytes (original URL, short code, metadata)
- Total URLs = 100M/month × 12 × 10 = 12B URLs
- Storage = 12B × 500 bytes = 6 TB

With index overhead (30%):
- Total = 6 TB × 1.3 = 7.8 TB

Single database can handle this. No sharding needed.

Example 2: Design Netflix

Requirements: Bandwidth: 
CONCURRENT USERS (assume 10% watch at peak):
- 200M × 0.1 = 20M concurrent streams

BANDWIDTH:
- 20M × 5 Mbps = 100M Mbps = 100 Terabits/sec

This requires global CDN infrastructure (Akamai, Cloudflare).
Netflix uses Open Connect (their own CDN).
Storage: 
CATALOG:
- 10,000 movies/shows
- Average movie = 2 hours = 4.5 GB (at 5 Mbps)
- Multiple qualities (SD, HD, 4K) = 3x
- Total = 10,000 × 4.5 GB × 3 = 135 TB

Manageable. Real Netflix has ~100 PB due to regional caching.

Example 3: Design Uber

Requirements: QPS: 
RIDE REQUESTS:
- 100M × 2 = 200M requests/day
- Average = 200M / 86,400 ≈ 2,300 QPS
- Peak = 6,900 QPS

LOCATION UPDATES:
- 10M drivers × (86,400 / 5) = 10M × 17,280 = 172.8B updates/day
- Average = 172.8B / 86,400 = 2M QPS
- Peak = 6M QPS

Location updates dominate. Need stream processing (Kafka).

Example 4: Design WhatsApp

Requirements: QPS: 
MESSAGES:
- 2B × 50 = 100B messages/day
- Average = 100B / 86,400 ≈ 1.16M messages/sec
- Peak = 3.5M messages/sec
Storage (5 years): 
- Daily = 100B × 100 bytes = 10 TB/day
- 5 years = 10 TB × 365 × 5 = 18,250 TB ≈ 18 PB

With replication (3x) = 54 PB

Need distributed storage (Cassandra, HBase).

Example 5: Design Google Drive

Requirements: Storage: 
TOTAL STORAGE:
- 500M × 10 GB = 5 Exabytes

With replication (1.5x for erasure coding):
- 5 EB × 1.5 = 7.5 Exabytes
QPS: 
UPLOADS:
- 500M × 10 = 5B uploads/day
- Average = 5B / 86,400 ≈ 58K uploads/sec
- Peak = 174K uploads/sec

File uploads are bursty, need queue (SQS, RabbitMQ).

Quick Reference Card

Memorize These:

Time:
- 1 day = 86,400 sec ≈ 100K
- 1 month = 2.5M sec
- 1 year = 30M sec

QPS:
- 1M requests/day ≈ 12 QPS
- 100M DAU × 10 actions = 1B req/day ≈ 12K QPS
- Peak = 2-3x average

Storage:
- 1 KB = 1,000 bytes
- 1 MB = 1,000 KB
- 1 GB = 1,000 MB
- 1 TB = 1,000 GB
- 1 PB = 1,000 TB

Data Sizes:
- Tweet = 500 bytes
- Photo = 2-5 MB
- Video (1 min HD) = 50-100 MB

Server Capacity:
- API server = 1-5K QPS
- Cache (Redis) = 10-100K QPS
- Database (SQL) = 1-5K QPS

Summary

Final Tip: Don't over-optimize accuracy. Saying "approximately 100K QPS" is better than spending 3 minutes on exact math. The interviewer wants to see your thought process, not your calculator skills.