Chapter 42: Capacity Planning & Estimation

The Art of Back-of-Envelope Math

Capacity planning turns vague requirements into concrete numbers. In system design interviews and real production systems, the ability to estimate traffic, storage, bandwidth, and compute requirements separates good engineers from great ones. This chapter teaches you the frameworks and math to plan for scale.

1. Why Capacity Planning Matters

Capacity planning is the bridge between architecture and operations. Without it:

  • Outages from growth: Systems fall over when traffic exceeds capacity. Black Friday crashes, viral posts bringing down services, database connection exhaustion.
  • Cost explosions: Over-provisioning wastes money. A 2x over-provision across 1000 servers costs millions annually.
  • Slow procurement: Hardware and cloud quota increases take time. Without planning, you cannot scale fast enough.
  • Wrong technology choices: Pick MongoDB for 10 TB data, realize later it should have been S3 + metadata DB.

Goals of Capacity Planning

  • Avoid outages: Provision for peak load plus headroom (typically 30-50%).
  • Optimize cost: Right-size resources. Use auto-scaling where appropriate.
  • Inform architecture: Storage estimates determine if you need sharding, CDN decisions flow from bandwidth math.
  • Set SLOs: Capacity constraints inform what latency and availability you can promise.
Interview Tip: Always start system design with capacity estimation. It shows structured thinking and often reveals architectural requirements (caching, sharding, CDN) naturally.

2. Estimation Framework

Follow this four-step process for any capacity estimation:

graph LR A[Requirements] --> B[Assumptions] B --> C[Calculations] C --> D[Validate] D --> E[Adjust Architecture] style A fill:#667eea,color:#fff style B fill:#764ba2,color:#fff style C fill:#f093fb,color:#fff style D fill:#4facfe,color:#fff style E fill:#43e97b,color:#fff

Step 1: Gather Requirements

  • How many users? Daily active users (DAU), monthly active users (MAU)?
  • What actions do they perform? Frequency per user?
  • What data is stored? Size per record? Retention period?
  • Read-heavy or write-heavy? Ratio?

Step 2: State Assumptions

Be explicit. Round to make math easy. Examples:

  • "Assume 100M DAU"
  • "Average user posts 2 tweets per day"
  • "Each tweet is 200 bytes text + 1 MB media (20% have media)"
  • "Read:write ratio = 100:1"
  • "Peak traffic = 3x average"

Step 3: Do the Math

Work through traffic, storage, bandwidth, compute step by step. Show your work in interviews.

Step 4: Validate and Adjust

Sanity check: Does 1 PB of storage sound right for 100M users? Compare to known systems (Twitter has ~500M DAU). Adjust architecture based on numbers (e.g., "We need sharding" if DB exceeds single-server capacity).

Interview Tip: Always say assumptions out loud and wait for interviewer to agree. "I'll assume 100 million daily active users, does that sound right?" This shows collaboration and avoids going down the wrong path.

3. Traffic Estimation

Traffic estimation converts user behavior into queries per second (QPS), the fundamental unit for capacity planning.

QPS = (DAU × actions_per_day) / 86400

Where 86400 = seconds per day (24 × 60 × 60)

Average vs Peak Traffic

Traffic is not uniform. Peak traffic typically 2-3x average:

  • Social media: Evenings and weekends, 2-3x average
  • E-commerce: Lunch hours, Black Friday (10x+ average)
  • Enterprise B2B: Business hours, relatively flat (1.5x average)
Peak QPS = Average QPS × Peak Multiplier (2-3x)

Worked Example: Instagram

Given:
- DAU = 500 million users
- Each user views 50 photos per day
- Each user uploads 1 photo per day
Read QPS:
= (500M × 50) / 86400
= 25,000,000,000 / 86400
≈ 289,000 QPS average
Write QPS:
= (500M × 1) / 86400
= 500,000,000 / 86400
≈ 5,800 QPS average
Peak Read QPS: 289K × 3 = ~870K QPS
Peak Write QPS: 5.8K × 3 = ~17K QPS
Read:Write Ratio: 50:1

Breaking Down by Endpoint

For more precision, estimate per-API:

Endpoint Actions/User/Day Avg QPS Peak QPS
View feed 20 115,000 345,000
View photo 50 289,000 867,000
Like photo 10 58,000 174,000
Upload photo 1 5,800 17,400
Post comment 3 17,400 52,200
Interview Tip: Separate reads and writes from the start. Read-heavy systems need caching; write-heavy systems need queue buffering and write optimization.

4. Storage Estimation

Storage grows over time. Estimate using:

Total Storage = Records per Day × Size per Record × Retention Days

Media Dominates

Text is cheap. Media (images, videos) dominates storage:

  • Tweet text: ~200 bytes
  • Tweet with image: ~1 MB (5,000x larger)
  • Short video: ~10 MB (50,000x larger)
  • HD video: ~1 GB (5,000,000x larger)

Worked Example: Twitter Storage

Given:
- 500M DAU
- 2 tweets per user per day
- Each tweet: 200 bytes text
- 20% of tweets have image (1 MB)
- 5% of tweets have video (10 MB)
- Retention: Forever (10 years for estimation)
Tweets per day:
= 500M × 2 = 1 billion tweets/day
Text storage per day:
= 1B × 200 bytes = 200 GB/day
Image storage per day:
= 1B × 0.20 × 1 MB = 200M MB = 200 TB/day
Video storage per day:
= 1B × 0.05 × 10 MB = 50M MB = 50 TB/day
Total per day: ~250 TB/day
Total per year: 250 TB × 365 = ~91 PB/year
10-year storage: ~910 PB ≈ 1 Exabyte

Architectural implication: Media goes to object storage (S3), not database. Metadata only in DB.

Storage Growth Pattern

graph LR A[Year 1: 91 PB] --> B[Year 2: 182 PB] B --> C[Year 3: 273 PB] C --> D[Year 4: 364 PB] D --> E[Year 5: 455 PB] style A fill:#43e97b style E fill:#fa709a

Storage is cumulative and grows linearly with retention. Plan for multi-year growth.

Interview Tip: Always separate metadata (goes to DB) from media (goes to S3/blob storage). This is a key architectural decision that falls out of storage math.

5. Bandwidth Estimation

Bandwidth = how much data flows in and out per second.

Bandwidth = QPS × Average Response Size

Upload vs Download

Most systems are download-heavy (read-heavy):

  • Upload (ingress): User-generated content, writes
  • Download (egress): Serving content to users, reads

Worked Example: Instagram Bandwidth

From earlier:
- Read QPS: 289K average, 870K peak
- Write QPS: 5.8K average, 17.4K peak
- Average photo size: 1 MB
Download bandwidth (average):
= 289,000 QPS × 1 MB
= 289,000 MB/s = 289 GB/s = 2.3 Tbps
Download bandwidth (peak):
= 870,000 QPS × 1 MB = 870 GB/s = 7 Tbps
Upload bandwidth (average):
= 5,800 QPS × 1 MB = 5.8 GB/s = 46 Gbps
Egress: 2.3 Tbps average, 7 Tbps peak
Ingress: 46 Gbps average

CDN Offload

CDN can serve 90-95% of reads, dramatically reducing origin bandwidth:

With 95% CDN hit rate:
Origin egress = 2.3 Tbps × 0.05 = 115 Gbps average
CDN serves the rest

Architectural implication: CDN is mandatory for media-heavy systems. Otherwise, bandwidth costs explode.

Interview Tip: High bandwidth numbers (Tbps) naturally lead to discussing CDN. This shows you understand cost optimization and global distribution.

6. Compute Estimation

Compute estimation: How many servers do we need?

Servers Needed = Peak QPS / QPS per Server

Single-Server Capacity

Rule of thumb (actual numbers vary by workload):

  • Simple API (read from cache): 10,000 QPS
  • Database read: 1,000 QPS
  • Database write: 500 QPS
  • Complex computation: 100 QPS
  • ML inference: 10-100 QPS (depends on model)

Always benchmark your actual workload. These are starting points.

Worked Example: API Servers for Twitter

From earlier:
- Peak read QPS: 870K
- Peak write QPS: 17.4K
- Assume read = simple API (cache): 10K QPS per server
- Assume write = DB write: 500 QPS per server
Read servers needed:
= 870,000 / 10,000 = 87 servers (raw)
Add 30% headroom:
= 87 × 1.3 = 113 servers
Write servers needed:
= 17,400 / 500 = 35 servers (raw)
= 35 × 1.3 = 46 servers (with headroom)
Total API servers: ~160 servers
(113 read-focused + 46 write-focused)

Headroom and Redundancy

  • Headroom (30-50%): Buffer for traffic spikes, slow queries, degraded instances.
  • Multi-AZ redundancy: 2x (active-active in 2 AZs) or 1.5x (active-passive).
  • Rolling deployment capacity: Need capacity to keep running while deploying new code (typically 20% extra).

Real-world multiplier: 1.3 (headroom) × 2 (multi-AZ) = 2.6x raw calculation, or ~3x rule of thumb.

Interview Tip: Always add headroom. Saying "we need exactly 87 servers" signals you don't understand production realities. Add 30-50% and explain why.

7. Database Sizing

Databases have multiple capacity dimensions:

Storage Capacity

  • Total data size (from storage estimation)
  • Index size (typically 10-30% of data size)
  • Does working set fit in RAM? (Hot data that must be in memory for performance)

Connection Capacity

Each server holds a connection pool. Typical limits:

  • PostgreSQL: Default max 100 connections, tunable to ~500
  • MySQL: Default max 151 connections, tunable to ~1000
  • MongoDB: No hard limit, but memory per connection
Example:
- 100 API servers
- Each with connection pool of 20
- Total connections = 100 × 20 = 2,000 connections
- PostgreSQL default (100) is insufficient → need replicas or connection pooler (PgBouncer)

IOPS Capacity

Input/output operations per second. Critical for database performance:

  • HDD: ~100 IOPS
  • SSD: ~10,000 IOPS
  • NVMe SSD: ~100,000 IOPS
  • AWS io2: Up to 64,000 IOPS per volume
Example:
- Peak write QPS: 17.4K
- Assume each write = 2 IOPS (index update + data write)
- Total IOPS needed: 17,400 × 2 = 34,800 IOPS
- SSD (10K IOPS) insufficient → need 4 SSDs in RAID or high-IOPS cloud storage

Read/Write Ratio Impact

Read-heavy systems (100:1) benefit from read replicas:

graph TD A[Primary DB] --> B[Replica 1] A --> C[Replica 2] A --> D[Replica 3] E[Writes] --> A F[Reads] --> B F --> C F --> D style A fill:#fa709a style B fill:#43e97b style C fill:#43e97b style D fill:#43e97b

Architectural implication: With 100 replicas, replication lag becomes a concern. Consider caching layer (Redis) to offload DB reads.

Interview Tip: If your math shows dozens of read replicas, immediately pivot to caching (Redis, CDN). This shows you understand the limits of replication and the need for tiered caching.

8. Worked Example: Design Twitter

Requirements

  • 500M daily active users (DAU)
  • Each user posts 2 tweets per day
  • Each user reads 100 tweets per day (timeline)
  • 20% of tweets have an image (1 MB)
  • 10-year retention

1. Traffic Estimation

Write QPS:
= (500M × 2) / 86400 = 11,600 QPS average
Peak (3x) = 35,000 QPS
Read QPS (timeline):
= (500M × 100) / 86400 = 580,000 QPS average
Peak (3x) = 1.74M QPS
Read:Write Ratio = 50:1
System is read-heavy → caching critical

2. Storage Estimation

Tweets per day:
= 500M × 2 = 1 billion tweets/day
Text storage:
= 1B × 200 bytes = 200 GB/day
= 73 TB/year
Image storage:
= 1B × 0.20 × 1 MB = 200 TB/day
= 73 PB/year
10-year storage:
Text: 730 TB
Images: 730 PB
Total: ~730 PB

3. Bandwidth Estimation

Tweet reads (peak):
= 1.74M QPS
Assume 20% have image = 1.74M × 0.20 = 348K image requests/sec
= 348K × 1 MB = 348 GB/s = 2.8 Tbps
Tweet writes (peak):
= 35K QPS × 0.20 × 1 MB = 7 GB/s = 56 Gbps
With 95% CDN offload:
Origin egress: 2.8 Tbps × 0.05 = 140 Gbps
CDN must handle ~2.7 Tbps

4. Compute Estimation

API servers (read):
Peak QPS: 1.74M
Assume cached read: 10K QPS per server
= 1.74M / 10K = 174 servers
With headroom (1.3x): 226 servers
API servers (write):
Peak QPS: 35K
Assume DB write: 500 QPS per server
= 35K / 500 = 70 servers
With headroom: 91 servers
Total API servers: ~320
(With multi-AZ: ~640 servers)

5. Database Sizing

Metadata only in DB:
Tweet metadata: 200 bytes × 365B tweets/year = 73 TB/year
With indexes (×1.3): 95 TB/year
10-year total: 950 TB
Sharding required:
950 TB exceeds single-server capacity
With 1 TB per shard → 950 shards (round to 1024 for power of 2)
Read replicas:
Peak read QPS: 1.74M
If only 5% hit DB (rest cached) = 87K QPS
At 10K QPS per replica = 9 replicas per shard
Total replicas: 1024 shards × 9 = 9,216 replicas
Database footprint:
1,024 primary shards
~9,000 read replicas
This is why Redis cache is critical!

6. Fan-out Consideration

When a user posts a tweet, it must appear in followers' timelines (fan-out):

Average user has 200 followers
1B tweets/day × 200 followers = 200B timeline inserts/day
= 2.3M writes/sec average (7M peak)

Architectural implication: Cannot fan-out synchronously. Use message queue (Kafka) + async workers to fan-out. Celebrities (millions of followers) need special handling (fan-out on read, not write).

Interview Key Takeaways: This example shows how numbers drive architecture. 730 PB → S3, not DB. 1.74M read QPS → Redis cache mandatory. 7M fan-out writes/sec → async queue required. Numbers reveal system structure.

9. Worked Example: Design YouTube

Requirements

  • 2B daily active users (DAU)
  • Each user watches 5 videos per day
  • Upload rate: 500 hours of video per minute
  • Average video: 10 minutes, 50 MB (720p)
  • Store multiple resolutions: 360p, 720p, 1080p, 4K
  • 10-year retention

1. Traffic Estimation

Video views:
= (2B × 5) / 86400 = 116,000 views/sec average
Peak (3x) = 348,000 views/sec
Uploads:
500 hours/minute = 30,000 hours/hour
= 500 minutes/minute = 8.3 videos/sec (at 10 min average)
Peak (3x) = 25 uploads/sec
Read:Write Ratio = 116K:8 = 14,500:1
Extremely read-heavy → CDN delivers 99%+ of traffic

2. Storage Estimation

Uploads per day:
= 500 hours/min × 60 min/hour × 24 hours
= 720,000 hours of video/day
At 10 min average = 4.32M videos/day
Storage per video (multiple resolutions):
360p: 20 MB
720p: 50 MB
1080p: 100 MB
4K: 400 MB
Total per video: 570 MB
Daily storage:
= 4.32M videos × 570 MB
= 2.46 PB/day
Annual storage: 2.46 PB/day × 365 = 898 PB/year
10-year storage: ~9 Exabytes

3. Transcoding Compute

Each uploaded video must be transcoded to multiple resolutions.

Transcoding time:
Assume 1 minute of video takes 5 minutes to transcode (all resolutions)
4.32M videos/day × 10 min/video = 43.2M minutes of source video/day
Transcoding required: 43.2M × 5 = 216M minutes/day of compute
Transcoding servers:
= 216M minutes/day / 1440 minutes/day
= 150,000 servers running 24/7
Cost optimization:
Use spot instances, pre-encode popular resolutions only, encode others on-demand
Reduce to ~30K servers with smart prioritization

4. Bandwidth Estimation

Video views (peak):
348K views/sec
Average bitrate (assuming mix of resolutions): 5 Mbps
= 348K × 5 Mbps = 1.74 Terabits/sec = 1.74 Tbps
Upload bandwidth:
25 uploads/sec × 50 MB = 1.25 GB/sec = 10 Gbps
With 99% CDN offload:
Origin serves only 1% = 17.4 Gbps
CDN handles 1.72 Tbps

5. Database Sizing

Metadata per video:
Video ID, title, description, uploader, timestamps, view count, etc.
Assume 5 KB per video
Annual metadata:
4.32M videos/day × 365 days × 5 KB
= 7.88 TB/year
10-year metadata:
= 78.8 TB (with indexes: ~100 TB)
Sharding:
100 TB fits on ~10 shards (10 TB each)
Each shard needs read replicas for 116K reads/sec
With caching (95% cache hit), only 5.8K reads/sec hit DB
1 replica per shard sufficient

6. Caching Strategy

Video popularity follows power law: 20% of videos get 80% of views.

Hot videos (1% of catalog):
Served from CDN edge cache (millisecond latency)
Warm videos (19% of catalog):
Served from CDN regional cache (10-50ms latency)
Cold videos (80% of catalog):
Served from origin S3 (100-300ms latency)

Architectural implication: Multi-tier CDN is mandatory. Single-tier CDN cannot cache 9 Exabytes.

Interview Key Takeaways: YouTube's scale requires extreme specialization. 9 Exabytes → object storage only option. 150K transcode servers → massive compute need, use spot. 1.74 Tbps → multi-tier CDN mandatory. Power-law caching essential.

10. Growth Modeling

Capacity planning is not one-time. Model growth over time.

Linear vs Exponential Growth

graph LR A[Linear: +X users/month] --> B[Predictable] C[Exponential: ×Y % /month] --> D[Viral/Unpredictable] style A fill:#43e97b style C fill:#fa709a
  • Linear growth: Mature products, steady user acquisition. Add X users per month. Example: Enterprise SaaS growing by 1000 customers/month.
  • Exponential growth: Early-stage viral products. Grow by Y% per month. Example: TikTok growing 20% month-over-month.

Doubling Time

For exponential growth, doubling time tells you when capacity runs out.

Doubling Time (months) ≈ 70 / Growth Rate %
Example:
Growing 10% per month
Doubling time = 70 / 10 = 7 months
If you provision for 2x current capacity, you have 7 months before you run out

Planning Horizon

  • 6 months: Minimum for stable growth. Allows time to procure hardware, negotiate contracts.
  • 12 months: Standard for most companies. Annual capacity planning cycle.
  • 18-24 months: For very high-growth or long-lead-time infrastructure (datacenters, subsea cables).

Example Growth Projection

Month Users (10% growth) QPS Storage (TB)
0 (Now) 100M 200K 1,000
3 133M 266K 1,330
6 177M 354K 1,770
12 314M 628K 3,140
18 556M 1.1M 5,560

Auto-Scaling vs Pre-Provisioning

Auto-Scaling (Elastic)

  • Pros: Cost-efficient (pay for what you use), handles unpredictable spikes
  • Cons: Slower to scale (5-10 min to add instances), quotas can block scale-up
  • Best for: Compute (web servers, workers), stateless services

Pre-Provisioning (Reserved Capacity)

  • Pros: Instant capacity, no quota issues, cost savings (reserved instances)
  • Cons: Pay for idle capacity, less flexible
  • Best for: Databases, caches, steady-state baseline capacity

Hybrid approach: Pre-provision baseline (steady-state), auto-scale for peaks. Example: 100 servers reserved, auto-scale up to 200 for traffic spikes.

Interview Tip: When discussing growth, mention auto-scaling AND pre-provisioning. Show you understand both cost optimization (auto-scale) and reliability (pre-provision critical components like DB).

11. Common Numbers Reference Card

Memorize these for quick estimation in interviews:

Time Constants

Operation Latency
L1 cache reference 0.5 ns
L2 cache reference 7 ns
Main memory reference 100 ns
SSD random read 150 Ξs
HDD seek 10 ms
Network within datacenter 0.5 ms
Network cross-continent 150 ms

Throughput Numbers

System Throughput
Web server (simple API) 10,000 QPS
DB read query 1,000 QPS
DB write query 500 QPS
Redis GET 100,000 QPS
Redis SET 80,000 QPS
Kafka write 1M msg/sec
SSD sequential read 500 MB/s
Network (1 Gbps NIC) 125 MB/s

Size of Common Data

Data Type Size
UUID / GUID 16 bytes
Integer (64-bit) 8 bytes
Timestamp 8 bytes
Tweet (text only) 200 bytes
Compressed image (JPEG) 200 KB - 2 MB
High-res photo 5-10 MB
1 minute video (720p) 10 MB
1 hour HD movie 1-2 GB

Conversion Factors

Conversion Value
1 KB 1,000 bytes
1 MB 1,000 KB = 10^6 bytes
1 GB 1,000 MB = 10^9 bytes
1 TB 1,000 GB = 10^12 bytes
1 PB 1,000 TB = 10^15 bytes
Seconds per day 86,400 (≈ 100K)
Seconds per year 31,536,000 (≈ 30M)
Interview Tip: You don't need to memorize exact numbers. Interviewers accept approximations (86,400 → 100K is fine). What matters is using consistent assumptions and showing your math.

Summary

Key Principles of Capacity Planning

  • Start with users and behavior: DAU, actions per day, read/write ratio
  • Work through layers: Traffic (QPS) → Storage (TB) → Bandwidth (Gbps) → Compute (servers) → Database (IOPS, connections)
  • State assumptions explicitly: Round numbers to make math easy. Wait for interviewer confirmation.
  • Show your work: Step-by-step calculations reveal your thought process
  • Let numbers drive architecture: High bandwidth → CDN. Read-heavy → caching. Multi-TB → sharding. This is the goal!
  • Always add headroom: 30-50% buffer for spikes, failures, growth
  • Model growth: Plan 6-18 months out. Understand doubling time for exponential growth.
  • Validate with reality: Does 1 PB for 100M users sound right? Compare to known systems.

Common Interview Mistakes

  • Skipping estimation: Jumping straight to architecture without numbers. Always estimate first!
  • No headroom: Saying "we need exactly 87 servers" signals inexperience. Add buffer.
  • Ignoring peak traffic: Using average QPS to size systems. Always plan for peak (2-3x average).
  • Mixing metadata and media: Putting images in database instead of S3. Storage math reveals this.
  • Not connecting numbers to architecture: Doing math but not using it to justify CDN, caching, sharding. Numbers should drive design decisions.

Capacity Planning Checklist

  1. Clarify requirements (DAU, actions, data types, retention)
  2. Estimate traffic (QPS average and peak, read/write ratio)
  3. Estimate storage (per-record size, growth over time)
  4. Estimate bandwidth (QPS × response size, CDN offload)
  5. Estimate compute (peak QPS / server capacity, add headroom)
  6. Size database (storage, IOPS, connections, replicas)
  7. Use numbers to justify architecture choices (cache, CDN, sharding)
  8. Model growth and plan for next 6-18 months

Remember: The goal of capacity planning in interviews is not perfect accuracy. It's demonstrating structured thinking, making reasonable assumptions, and letting quantitative analysis drive architectural decisions. Master this, and you'll ace the capacity estimation portion of any system design interview.