Back-of-the-Envelope Estimation

Master the art of quick system capacity estimation. Learn the patterns and formulas that help you calculate QPS, storage, bandwidth, and server requirements in minutes - a crucial skill for system design interviews and real-world planning.

What is Back-of-the-Envelope Estimation?

A method for making quick, rough calculations to estimate system requirements. The name comes from the idea that these calculations are simple enough to do on the back of an envelope.

✓ Good Enough

Aim for order of magnitude accuracy (within 10x)

✓ Fast

Complete estimation in 5-10 minutes

✓ Systematic

Follow repeatable patterns

The Universal Estimation Pipeline

🔄 The Standard Flow

DAU → Operations/Day → QPS → Storage → Bandwidth → Servers

Input: Daily Active Users

Output: Infrastructure Requirements

Essential Constants & Conversions

⏰ Time Constants

1 minute = 60 seconds

1 hour = 3,600 seconds

1 day = 86,400 ≈ 100K seconds

1 month = 2.6M seconds

1 year = 31.5M ≈ 30M seconds

💡 Use approximations (100K, 30M) for faster mental math

💾 Storage Units

1 KB = 10³ bytes = 1,000 bytes

1 MB = 10⁶ bytes = 1,000 KB

1 GB = 10⁹ bytes = 1,000 MB

1 TB = 10¹² bytes = 1,000 GB

1 PB = 10¹⁵ bytes = 1,000 TB

💡 Use powers of 10, not powers of 2 (1024) for estimation

Common Data Sizes

Data Type	Size	Example
Character	1 byte	'A', '1', '!'
Integer	4 bytes	user_id (32-bit)
Long/BigInt	8 bytes	timestamp, ID (64-bit)
UUID	16 bytes	session_id
Email	50 bytes	user@example.com
Tweet	280-500 bytes	text + metadata
Photo (compressed)	1-2 MB	Instagram photo
Video (1min, 1080p)	50-100 MB	TikTok video

Pattern 1: Calculating QPS (Queries Per Second)

📊 From DAU to QPS

The Formula:

Average QPS = (DAU × Operations per User per Day) / 86,400 seconds
Peak QPS = Average QPS × Peak Factor (2-5x)

Example: Twitter-like System

Given:

• 50M DAU

• 20 tweets read per user per day

• 2 tweets written per user per day

Calculation:

Total reads/day = 50M × 20 = 1B reads

Total writes/day = 50M × 2 = 100M writes

Read QPS = 1B / 86,400 ≈ 11,600 QPS

Write QPS = 100M / 86,400 ≈ 1,160 QPS

Peak (3x):

Peak Read QPS = 11,600 × 3 = 34,800 QPS

Peak Write QPS = 1,160 × 3 = 3,480 QPS

Read/Write Ratio Patterns

📖 Read-Heavy Systems

• Social Media: 100:1
• E-commerce: 10:1
• News Sites: 1000:1
• Banking: 5:1

✍️ Write-Heavy Systems

• Analytics/Logging: 1:10
• IoT Data: 1:100
• Time Series: 1:50
• Chat/Messaging: 1:1

Pattern 2: Storage Estimation

💾 Calculating Storage Requirements

The Formula:

Storage = DAU × Items per User per Day × Item Size × Retention Period
Add: Replication Factor (typically 3x)
Add: Growth Buffer (20-30%)

Example: WhatsApp Storage

Given:

• 2B DAU

• 50 messages per user per day

• 90% text (100 bytes), 8% images (1MB), 2% videos (50MB)

• Retain for 2 years

Daily Storage:

Messages/day = 2B × 50 = 100B messages

Text: 100B × 0.9 × 100 bytes = 9 TB/day

Images: 100B × 0.08 × 1MB = 80 TB/day

Videos: 100B × 0.02 × 50MB = 100 PB/day

Total daily = 9 TB + 80 TB + 100 PB ≈ 100 PB/day

2-Year Storage:

100 PB/day × 365 days × 2 years = 73,000 PB = 73 EB

With 3x replication = 219 EB

Pattern 3: Bandwidth Calculation

🌐 Network Bandwidth Requirements

The Formula:

Bandwidth = QPS × Average Request/Response Size
Inbound = Write QPS × Request Size
Outbound = Read QPS × Response Size

Example: Video Streaming Platform

Given:

• 100M DAU

• 5 videos watched per user per day

• Average video: 100MB

• 20% of video watched on average

Calculation:

Videos/day = 100M × 5 = 500M videos

Data/day = 500M × 100MB × 0.2 = 10 PB/day

Average bandwidth = 10 PB / 86,400s = 116 GB/s

Peak bandwidth (3x) = 348 GB/s

Per Server (1 Gbps network):

348 GB/s = 348 × 8 = 2,784 Gbps needed

Servers needed = 2,784 / 1 Gbps = 2,784 servers

Pattern 4: Server Estimation

🖥️ Server Requirements

Server Type	Typical Capacity	Use Case
Web Server	1-2K QPS	API endpoints, static content
Application Server	500-1K QPS	Business logic, processing
MySQL/PostgreSQL	1K QPS	ACID transactions
NoSQL (Cassandra)	10K QPS	High throughput writes
Cache (Redis)	100K QPS	Session, hot data
CDN Edge	10-50K QPS	Static assets, media

Complete Example: Design Twitter

🐦 Full Estimation Walkthrough

Step 1: Define Scale

• DAU: 300M users

• Tweets per user: 2 per day

• Tweet reads per user: 50 per day

• Media in tweets: 20% have images, 5% have videos

• Follow relationships: 200 on average

• Retention: 5 years for tweets, 1 year for media

Step 2: Calculate QPS

Tweet Operations:

Write tweets/day = 300M × 2 = 600M

Read tweets/day = 300M × 50 = 15B

Write QPS = 600M / 86,400 = 7K QPS

Read QPS = 15B / 86,400 = 174K QPS

Peak (3x):

Peak Write = 21K QPS

Peak Read = 522K QPS

Step 3: Estimate Storage

Tweet Text:

Size per tweet = 280 bytes + 200 bytes metadata = 500 bytes

Daily storage = 600M × 500 bytes = 300 GB/day

5 years = 300 GB × 365 × 5 = 548 TB

Media Storage:

Images: 600M × 0.2 × 2MB = 240 GB/day

Videos: 600M × 0.05 × 100MB = 3 TB/day

1 year media = (240 GB + 3 TB) × 365 = 1.2 PB

Total: 548 TB + 1.2 PB ≈ 1.7 PB

With 3x replication = 5.1 PB

Step 4: Calculate Bandwidth

Text Bandwidth:

Read: 522K QPS × 500 bytes = 261 MB/s

Write: 21K QPS × 500 bytes = 10.5 MB/s

Media Bandwidth:

Image reads (10% include image): 52K × 2MB = 104 GB/s

Video reads (1% include video): 5.2K × 100MB = 520 GB/s

Total Peak: 624 GB/s outbound

Step 5: Server Requirements

Application Servers:

522K read QPS / 1K per server = 522 servers

Add 30% buffer = 680 servers

Database Servers:

21K write QPS / 1K per server = 21 write masters

522K read QPS / 10K per server = 53 read replicas

Cache Servers:

Hot data (20% of reads): 104K QPS

104K / 100K per Redis = 2 Redis instances

CDN Requirements:

624 GB/s / 10 Gbps per POP = 500 edge locations

Total Infrastructure:

• 680 app servers

• 74 database servers

• 2 cache servers

• 500 CDN POPs

Quick Reference: Estimation Template

📋 Copy-Paste Template

System: _______________

1. SCALE
 DAU: _______
 Operations per user: _______
 Read/Write ratio: _______

2. QPS CALCULATION
 Total operations/day: _______
 Average QPS = _______ / 86,400 = _______
 Peak QPS (3x) = _______
 Read QPS = _______
 Write QPS = _______

3. STORAGE
 Item size: _______
 Daily new data: _______
 Retention period: _______
 Total storage = _______
 With replication (3x) = _______

4. BANDWIDTH
 Request size: _______
 Response size: _______
 Inbound bandwidth = Write QPS × Request = _______
 Outbound bandwidth = Read QPS × Response = _______

5. SERVERS
 App servers = Peak QPS / 1K = _______
 DB servers = Write QPS / 1K = _______
 Cache servers = Hot Read QPS / 100K = _______
 
6. SANITY CHECK
 Does _______ sound reasonable for _______?

Common Pitfalls to Avoid

❌ Don't Do This

• Calculate to 3 decimal places
• Forget about peak traffic (3-5x)
• Ignore replication overhead
• Assume linear growth
• Use exact numbers (86,400 vs 100K)
• Forget media storage dominance
• Ignore geographic distribution

✅ Always Do This

• Round aggressively (1.7M → 2M)
• State assumptions clearly
• Add 20-30% growth buffer
• Consider cache hit rates
• Account for indices (1.5-2x data)
• Include monitoring overhead
• Sanity check final numbers

Practice Problems

🎯 Try These Yourself

1. Design URL Shortener

100M URLs shortened per day, 100:1 read ratio, 5 year retention

2. Design Instagram

500M DAU, 2 photos per user per day, 2MB per photo

3. Design Uber

10M daily rides, 50 location updates per ride, 100 bytes per update

4. Design Netflix

200M subscribers, 2 hours viewing per day, 3GB per hour

Summary

Back-of-the-envelope estimation is about speed and reasonable accuracy, not precision. Follow the patterns:

Start with users - Everything flows from DAU
Convert to operations - What do users do?
Calculate rates - QPS is operations/86,400
Estimate storage - Data × Time × Replication
Derive infrastructure - Servers based on load

Remember: The goal is to be within an order of magnitude (10x) and demonstrate systematic thinking. Practice these patterns and you'll be able to estimate any system in minutes!

💡 Interview Tip: Always state your assumptions out loud. If the interviewer disagrees with an assumption, they'll correct you. This shows clear thinking and gives them a chance to guide you toward their expectations.