How to Estimate Scale

Why Estimation Matters

Amazon interviewers expect you to estimate scale before designing. Estimation proves you can reason about real-world constraints. A design that works for 1M users but fails at 1B is not a good design. Estimation grounds your design in reality.

Key Numbers to Memorize

These numbers are your toolkit. Memorize them cold.

Time Constant	Value
1 day	86,400 seconds
1 hour	3,600 seconds
1 minute	60 seconds
1 million seconds	~11.5 days
1 billion seconds	~31.7 years

Traffic Rule of Thumb	Value
1 million requests/day	~12 QPS
100 million requests/day	~1,157 QPS
1 billion requests/day	~11,574 QPS

The Estimation Process

Follow these steps every time:

Step 1: Start with daily traffic

"If we have 100M daily active users, and each user makes 10 requests per day, that's 1B requests per day."

Step 2: Convert to QPS

"1B requests / 86,400 seconds = ~11,574 QPS average."

Step 3: Account for peaks

"Peak traffic is typically 2-3x average, so let's design for ~35,000 QPS."

Step 4: Estimate storage

"Each request writes 1KB of data. 100M writes/day × 1KB = 100GB/day. Over 5 years: ~180TB."

Step 5: Estimate cache

"If 80% of reads hit cache, we need cache for 80% of 900M reads = 720M entries. At 1KB each: ~720GB cache."

Estimation vs Precision

You don't need exact numbers. You need reasonable order-of-magnitude estimates.

Input	You Say	Interviewer Thinks
"100M users"	"~12K QPS"	Good approximation
"100M users"	"12,583 QPS"	Too precise, wastes time
"100M users"	"1M QPS"	Off by 10x, concerning

Round numbers are your friend. Use 10M, 100M, 1B — not 12,345,678.

The Presentation Flow

Present estimates like this:

"Let me estimate the scale. Assuming 100M daily active users, with 10 requests per user per day, we're looking at 1B total requests per day. That's roughly 12K QPS on average. With a 3x peak multiplier, we should design for 35-40K QPS."

This is clear, structured, and shows the interviewer your reasoning.

Common Mistakes

Mistake	Why It's Wrong	Correct Approach
Skipping peak traffic	Average QPS won't handle Prime Day	Always multiply by 2-3x
Forgetting storage growth	100GB/day × 365 days = 36.5TB/year	Always project over retention period
Ignoring read vs write	Reads and writes have different costs	Separate read QPS and write QPS
Not rounding	Shows poor number sense	Use round numbers (10M, 100M, 1B)

The 30-Second Estimation

Practice doing this in 30 seconds:

1. Daily traffic: X users × Y requests = Z requests/day
2. Average QPS: Z / 86,400
3. Peak QPS: Average × 3
4. Storage/day: Writes × payload size
5. Total storage: Storage/day × retention days

This becomes muscle memory with practice.

The Storage Formula

Total Storage = Daily Writes × Payload Size × Retention Days

This is the fundamental equation. Everything else is derived from it.

Storage Estimation Walkthrough

Example: URL Shortener

Given:

• 100M URLs created per day
• Each URL record: ~500 bytes (short URL, long URL, user ID, timestamp, metadata)
• Retention: 5 years (1,825 days)

Calculation:

Daily storage = 100M × 500 bytes = 50GB/day
Total storage = 50GB × 1,825 days = 91.25TB

Add 20% overhead for indexes and metadata:

Final estimate = 91.25TB × 1.2 = ~110TB

Data Types and Their Sizes

Data Type	Typical Size	Use Case
User ID	8-16 bytes	Unique identifier
Timestamp	8 bytes	Event time
URL	~100 bytes	Short URL
URL (long)	~500 bytes	Original URL
User profile	~1KB	Name, email, preferences
Tweet/Post	~500 bytes	Text content
Image metadata	~1KB	Dimensions, format, URL
Image (thumbnail)	~50KB	Compressed thumbnail
Image (original)	~2MB	Full resolution
Video metadata	~2KB	Title, duration, tags
Video (30s clip)	~10MB	Compressed video

Storage Tiers

Not all data needs the same storage tier. Design for cost efficiency:

Tier	Access Pattern	Storage Type	Cost
Hot	Accessed every request	SSD (EBS gp3)	$0.08/GB/month
Warm	Accessed daily/weekly	HDD (SC1)	$0.015/GB/month
Cold	Accessed monthly/quarterly	S3 Glacier	$0.004/GB/month
Archive	Rarely accessed	S3 Glacier Deep	$0.001/GB/month

Example: A URL shortener with 110TB total:

• Hot: 10TB (recent URLs, frequently accessed) — $800/month
• Warm: 30TB (older URLs, occasional access) — $450/month
• Cold: 70TB (archived URLs, rarely accessed) — $280/month
• Total: ~$1,530/month vs $8,800/month if all on SSD

Database Sizing

Amazon interviewers want to see you estimate database size specifically:

MySQL/PostgreSQL:

Row size = sum of all column sizes
Table size = row size × number of rows
With indexes = table size × 1.5-2x

Example: User table

user_id: 16 bytes (UUID)
name: 100 bytes
email: 200 bytes
created_at: 8 bytes
preferences: 500 bytes
────────────────────
Row size: ~824 bytes
100M users: 82.4GB
With indexes: ~125GB

DynamoDB:

Item size = sum of all attribute sizes
Storage = item size × number of items
With GSI = storage × (1 + number of GSIs)

Cache Size Estimation

Cache only the hot data:

Cache size = (Daily reads × % served from cache) × item size

Example: URL shortener with 900M reads/day, 80% cache hit rate:

Cached items = 900M × 0.8 = 720M
Item size = 500 bytes
Cache size = 720M × 500 bytes = 360GB

This is why Memcached/Redis clusters exist — single instances can't hold this.

Storage Projection Template

Use this template in interviews:

[Data type]: [count] × [size] = [daily/total]
[Data type]: [count] × [size] = [daily/total]
...
Total: [sum]
With overhead: [sum × 1.2]
Projected [N] years: [total × 365 × N]

The QPS Formula

Average QPS = (Daily requests) / 86,400
Peak QPS = Average QPS × Peak multiplier (2-3x)

QPS Walkthrough

Example: E-commerce Product Catalog

Given:

• 50M daily active users
• Each user views 20 products per day
• Each view = 1 read request

Calculation:

Daily reads = 50M × 20 = 1B reads/day
Average QPS = 1B / 86,400 = ~11,574 QPS
Peak QPS = 11,574 × 3 = ~35,000 QPS

For writes (product updates):

- 10,000 products updated per hour
- Writes = 10,000 / 3,600 = ~3 writes/sec
- Write QPS is negligible compared to reads

Read vs Write QPS

Always separate them. They have different characteristics:

Metric	Reads	Writes
Typical volume	10-100x writes	1x
Caching	Highly cacheable	Usually not cached
Consistency	Can tolerate staleness	Often need strong consistency
Scaling	Horizontal (replicas)	Vertical (sharding)

Example: URL Shortener

Writes: 100M URLs/day = 1,157 QPS
Reads: 1B redirects/day = 11,574 QPS (10:1 read:write)
Peak reads: 11,574 × 3 = 34,722 QPS

Bandwidth Estimation

Bandwidth = QPS × Payload size

Read bandwidth = Read QPS × Read response size
Write bandwidth = Write QPS × Write request size

Example: URL Shortener

Read bandwidth = 34,722 QPS × 500 bytes = 17.4 MB/s
Write bandwidth = 1,157 QPS × 500 bytes = 0.6 MB/s
Total bandwidth: ~18 MB/s = ~144 Mbps

QPS by System Type

System	Typical Read QPS	Typical Write QPS	Read:Write Ratio
URL Shortener	10K-100K	1K-10K	10:1
Social Feed	100K-1M	10K-100K	10:1
Chat System	10K-100K	10K-100K	1:1
E-commerce	50K-500K	1K-10K	50:1
Search Engine	100K-1M	1K-10K	100:1
Analytics	10K-100K	100K-1M	1:10

Peak Traffic Patterns

Peak isn't always 3x. It depends on the system:

System	Peak Pattern	Peak Multiplier
E-commerce	Prime Day, Black Friday	10-50x
Social Media	Evening hours	2-3x
Chat System	Business hours	2-3x
Streaming	Prime time (8-10 PM)	3-5x
Gaming	Weekends	2-4x

Server Estimation

Amazon expects you to estimate the number of servers:

Servers needed = Peak QPS / QPS per server

Typical QPS per server:

Server Type	QPS Capacity
Web server (Node.js/Go)	10K-50K QPS
API server (Java/Spring)	5K-20K QPS
Database read replica	5K-10K QPS
Cache server (Redis)	100K-500K QPS

Example: URL Shortener

Peak read QPS: 35,000
Web servers needed: 35,000 / 20,000 = 2 web servers
Cache servers needed: 35,000 / 200,000 = 1 cache server
DB read replicas: 35,000 / 5,000 = 7 read replicas

The Complete Estimation Template

Present your estimates in this format:

## Scale Estimation

### Traffic
- Daily active users: [X]
- Requests per user per day: [Y]
- Total daily requests: [X × Y]
- Average QPS: [X × Y / 86,400]
- Peak QPS: [Average × 3]

### Storage
- Writes per day: [Z]
- Payload per write: [S bytes]
- Daily storage: [Z × S]
- Retention: [N years]
- Total storage: [Daily × 365 × N]

### Bandwidth
- Read QPS × Response size = [X MB/s]
- Write QPS × Request size = [Y MB/s]

### Infrastructure
- Web servers: [Peak QPS / QPS per server]
- Cache size: [Reads × cache hit rate × item size]
- DB replicas: [Peak read QPS / QPS per replica]