Capacity Estimation

Back-of-envelope math done in the first 5 minutes of an interview. The goal is not precision — it's figuring out the order of magnitude so you know which layers to add and which problems to design for.

Numbers to Memorize

The handful of constants you need to do any back-of-envelope calculation in an interview — memorize these, everything else is derived.

Data Sizes

Common object sizes from a single byte to a minute of video — use these to estimate storage and bandwidth.

Unit	Size
1 character (ASCII)	1 byte
1 integer / timestamp	4–8 bytes
UUID / GUID	16 bytes
URL	~100 bytes
Tweet / short message	~300 bytes
User record (name, email, metadata)	~1 KB
Small image (thumbnail)	~50 KB
Photo (compressed JPEG)	~300 KB
High-res photo	~3 MB
Audio (1 min, compressed)	~1 MB
Video (1 min, 720p compressed)	~50 MB
Video (1 min, 1080p)	~150 MB
Web page (HTML + assets)	~2 MB

Time Conversions

Convert any time period to seconds so you can plug it directly into the QPS formula.

Period	Seconds
1 minute	60
1 hour	3,600
1 day	86,400 ≈ 10^5
1 month	2,500,000 ≈ 2.5 × 10^6
1 year	31,500,000 ≈ 3 × 10^7

Shortcut: 1 day ≈ 100,000 seconds. Use this for all QPS calculations.

Throughput Reference

What each order-of-magnitude QPS level means in terms of infrastructure complexity.

QPS	What It Means
1	Single server, trivial load
100	Small app, single DB handles it
1,000	Need caching, read replicas
10,000	Horizontal scaling, sharding
100,000+	CDN, distributed everything

Core Formulas

The four formulas that turn DAU and usage assumptions into QPS, storage, and bandwidth estimates.

QPS from DAU

Convert daily active users and average actions per user into requests per second.

QPS = DAU × requests_per_user_per_day / 86,400

Peak QPS = avg QPS × 2–3

Typical requests per user per day: 10–30 for most apps (social, e-commerce). Higher for messaging apps (100+).

Storage Per Day

How much new data the system writes each day across all users and events.

Daily storage = DAU × events_per_user_per_day × avg_event_size

Total Storage

Project long-term storage growth including the retention period and replication overhead.

Total storage = daily_storage × retention_days × replication_factor

Replication factor: typically 3 (one primary + two replicas for durability).

Bandwidth

Estimate network traffic in and out — ingress is driven by writes, egress by reads and payload sizes.

Ingress (write) bandwidth = write_QPS × avg_request_size
Egress (read) bandwidth  = read_QPS × avg_response_size

File Transfer Time

How long it takes to upload or download a file over a given connection. Useful any time the interview involves large file uploads (Dropbox, Google Drive, video upload).

Transfer time (seconds) = File size (GB) × 8 / Bandwidth (Mbps)

The × 8 converts gigabytes to gigabits so the units match.

Worked example — 50GB file on a 100Mbps connection:

50 GB × 8 bits/byte = 400 Gb
400 Gb / 100 Mbps   = 4,000 seconds
4,000 / 3,600       ≈ 1.1 hours

A single HTTP POST for this file would hold a connection open for over an hour. Most servers, load balancers, and mobile clients have timeouts well under that (30s–2min). This is why large file uploads require multipart upload — split the file into chunks (e.g. 4–8 MB each), upload each chunk independently, retry only failed chunks. The connection per chunk is short-lived and fits within any timeout window.

Quick reference — 100Mbps connection:

File Size	Transfer Time
100 MB	~8 seconds
1 GB	~80 seconds
10 GB	~13 minutes
50 GB	~1.1 hours
1 TB	~22 hours

Common bandwidths to know:

Connection	Bandwidth
4G mobile	~20–50 Mbps
Home broadband	~100–500 Mbps
Office / datacenter	~1–10 Gbps

Worked Example 1: Twitter

Full QPS, storage, and bandwidth estimate for a 300M DAU read-heavy social platform.

Given: 300M DAU. Users read 20 tweets/day, post 1 tweet every 3 days on average.

QPS

Write QPS = 300M × (1/3) / 86,400 = 100M / 86,400 ≈ 1,200 writes/sec
Read QPS  = 300M × 20  / 86,400 = 6B   / 86,400 ≈ 70,000 reads/sec
Peak read QPS ≈ 70,000 × 3 = ~200,000 reads/sec

→ Read/write ratio ≈ 60:1. Heavily read-heavy. CDN + Redis cache essential.

Storage

Tweet size = 300 bytes (text) + 500 bytes (metadata) = ~1 KB per tweet
Daily new tweets = 300M / 3 = 100M tweets/day
Daily storage = 100M × 1 KB = 100 GB/day
10-year storage = 100 GB × 365 × 10 = ~365 TB raw
With replication (×3) = ~1 PB

→ DB sharding needed. Media (photos/videos) stored in object storage separately.

Bandwidth

Write: 1,200 × 1 KB = ~1.2 MB/s ingress
Read:  70,000 × 1 KB = ~70 MB/s egress (text only)
       Add media: 70,000 × 10% × 300 KB = ~2 GB/s egress with photos

→ CDN absorbs media egress. Origin only serves cache misses.

Worked Example 2: YouTube

Storage and bandwidth estimate for a 2B DAU video platform — dominated by upload volume and streaming egress.

Given: 2B DAU. Users watch 30 min/day. 500 hours of video uploaded every minute.

Storage (uploads)

Upload rate = 500 hours/min × 60 min = 30,000 hours/day
Video size (1080p) = 150 MB/min = 9 GB/hour
Raw daily storage = 30,000 hours × 9 GB = 270 TB/day

YouTube stores multiple resolutions (360p, 720p, 1080p, 4K) = ~4× storage
With replication (×3) = 270 TB × 4 × 3 = ~3 PB/day

→ Object storage (S3-scale). DB only stores metadata (title, description, user_id, video_url).

QPS (views)

Watch time = 2B × 30 min = 60B min/day
Assuming avg video = 5 min → 12B video views/day
View QPS = 12B / 86,400 ≈ 140,000 QPS
Peak ≈ 400,000 QPS

Bandwidth (streaming)

Concurrent viewers = 2B × 30 min / (24 × 60 min) = ~42M concurrent at any time
Bitrate (720p) = ~2 Mbps
Total egress = 42M × 2 Mbps = 84 Tbps

→ 100% of video served from CDN. Impossible to serve from origin at this scale.

Worked Example 3: WhatsApp

QPS, storage, and bandwidth for a 2B DAU write-heavy messaging platform with significant media volume.

Given: 2B DAU. Each user sends 40 messages/day. 65B messages/day total.

QPS

Write QPS = 65B / 86,400 ≈ 750,000 messages/sec
Read QPS ≈ same (each message delivered to recipient)
Peak ≈ 2M QPS

→ Write-heavy at massive scale. Kafka to absorb burst. Cassandra for message storage (high write throughput, time-ordered).

Storage

Message size = ~100 bytes (text) + metadata
Daily storage = 65B × 100 bytes = 6.5 TB/day
Media (30% of messages, avg 300 KB) = 65B × 0.3 × 300 KB = ~5.8 PB/day

→ Text in Cassandra. Media in object storage (S3). WhatsApp deletes delivered media after 30 days to manage cost.

Bandwidth

Text: 750,000 × 100 bytes = ~75 MB/s
Media: 750,000 × 0.3 × 300 KB = ~67 GB/s

Estimation Cheat Sheet

Real-world scale anchors for the three worked examples — use these as reference points when estimating similar systems.

System	DAU	Avg QPS	Peak QPS	Daily Storage
Twitter (above)	300M	70K reads / 1.2K writes	~200K reads	~100 GB (text)
YouTube (above)	2B	140K views	~400K	~270 TB (video raw)
WhatsApp (above)	2B	750K msg/sec	~2M	~6.5 TB (text) + PBs (media)

Interview Tips

How to think and communicate during the estimation section — the interviewer cares about your reasoning, not your arithmetic.

Round aggressively. 86,400 → 10^5. 300M × 20 → 6B. Interviewers want the right order of magnitude, not exact math.
State your assumptions out loud. "I'll assume 10 requests per user per day." This shows structured thinking even if the number is off.
Derive the design from the numbers. "We have 70K read QPS — that's way beyond what a single DB can handle, so we need Redis cache in front and read replicas."
Flag what dominates. At YouTube, video storage and egress bandwidth dominate everything. At Twitter, read QPS dominates. Know which number is driving your design.
Storage units: 1 million × 1 KB = 1 GB. 1 billion × 1 KB = 1 TB. These two conversions cover most estimates.