Estimate Scale

Memory of Storage Units

Unit	Value	Power of 2
1 KB	1,024 bytes	2^10
1 MB	1,024 KB	2^20
1 GB	1,024 MB	2^30
1 TB	1,024 GB	2^40
1 PB	1,024 TB	2^50

Interview tip: For rough estimates, use powers of 10 for simplicity. 1 GB ≈ 10^9 bytes is close enough for most calculations.

Time Conversions (Must Memorize)

Time	Seconds
1 second	1
1 minute	60
1 hour	3,600
1 day	86,400
1 week	604,800
1 month	2,592,000 (30 days)
1 year	31,536,000 (365 days)

Quick shortcut: 1 day ≈ 86K seconds. 1 year ≈ 31.5 million seconds.

Scale Magnitudes

Number	Value	Real-World Example
1 thousand	10^3	Small blog daily views
1 million	10^6	Instagram likes per minute
1 billion	10^9	Google searches per day
1 trillion	10^12	Stars in Milky Way

Common Numbers to Memorize

Metric	Approximate Value
World population	8 billion
Internet users	5 billion
US population	330 million
Facebook DAU	2 billion
Google searches/day	8.5 billion
Amazon packages/day	10 million
Tweets/day	500 million
Hours of video uploaded to YouTube/minute	500
Average webpage size	2-3 MB
Average email size	75 KB
Average image size	2 MB
Average video (1 min, 1080p)	50-100 MB

Order of Magnitude Estimation

When you don't know exact numbers, estimate by order of magnitude:

1. Start with what you know (population, known user counts)
2. Apply reasonable percentages (10% adoption, 1% daily active)
3. Round to nearest power of 10

Example: "How many messages does WhatsApp handle daily?"

• World population: 8 billion
• Internet users: 5 billion
• WhatsApp users: ~2 billion (40% of internet users)
• Messages per user per day: ~40
• Total: 2B × 40 = 80 billion messages/day ≈ 10^11 messages/day

Storage Estimation Formula

Total Storage = Daily Active Users × Requests/Day × Storage/Request × Retention Days

Or broken down:

Storage = DAU × (write_size × writes_per_user + read_size × reads_per_user) × retention

Step-by-Step Process

1. Identify data types: What data do we store? (text, images, videos, metadata)
2. Estimate per-record size: How big is one unit of data?
3. Estimate write volume: How many writes per user per day?
4. Apply retention: How long do we keep data?
5. Add overhead: Indexes, metadata, replication factor

Example: Estimate Storage for Instagram

Given: 1B users, 100M photos uploaded per day

Step 1: Per-photo storage

• Original image: 2 MB (average)
• Thumbnails (3 sizes): 0.5 MB total
• Metadata (caption, tags, location): 5 KB
• Total per photo: ~2.5 MB

Step 2: Daily storage

100M photos/day × 2.5 MB = 250 TB/day

Step 3: Annual storage

250 TB/day × 365 days = 91.25 PB/year

Step 4: Add replication (3x for durability)

91.25 PB × 3 = 273.75 PB/year

Step 5: Add overhead for indexes and metadata (20%)

273.75 PB × 1.2 ≈ 328.5 PB/year

Answer: Instagram needs approximately 300-350 PB/year of raw storage.

Storage for Different Data Types

Data Type	Typical Size	Notes
Tweet	280 bytes text + metadata	Very small
Email	75 KB average	Text-heavy
Photo (mobile)	2-3 MB	Higher quality = 5-10 MB
Video (1 min, 1080p)	50-100 MB	Depends on compression
Database row	1-10 KB	Depends on schema
Log entry	0.5-2 KB	Structured data
JSON API response	1-10 KB	Varies widely

Interview Shortcut: Storage Estimation

For quick estimates, use this mental model:

1 million users × 1 MB/user/day = 1 TB/day
1 billion users × 1 KB/user/day = 1 TB/day

This helps you quickly bound the problem before diving into specifics.

QPS Estimation Formula

Average QPS = Daily Requests / 86,400 seconds
Peak QPS = Average QPS × Peak Factor (2-3x)

Peak factor depends on traffic patterns:

• Consistent traffic (Netflix streaming): 1.5-2x
• Business hours peak (enterprise SaaS): 2-3x
• Social media peak (evening): 3-5x
• Flash sale (Amazon Prime Day): 10-100x

Read vs Write Ratio

Most systems are read-heavy. Common ratios:

System	Read:Write Ratio
Social media feed	100:1
Wikipedia	1000:1
Chat application	10:1
IoT sensor data	1:10
Logging system	1:100

Why this matters: Read-heavy systems benefit from caching. Write-heavy systems need write-optimized storage.

Example: Estimate QPS for Twitter

Given: 300M daily active users, average user posts 2 tweets/day, views 200 tweets/day

Step 1: Write QPS (tweet creation)

Writes/day = 300M users × 2 tweets/user = 600M tweets/day
Average write QPS = 600M / 86,400 ≈ 6,944 QPS
Peak write QPS (3x) = 20,833 QPS

Step 2: Read QPS (timeline views)

Reads/day = 300M users × 200 views/user = 60B reads/day
Average read QPS = 60B / 86,400 ≈ 694,444 QPS
Peak read QPS (3x) = 2,083,333 QPS ≈ 2M QPS

Step 3: Fan-out considerations
When a celebrity tweets, their 100M followers need to see it. This is the fan-out problem:

• Celebrity tweet: 1 tweet triggers 100M timeline updates
• Solution: Pull-based for celebrities, push-based for regular users

QPS Sizing Rules

QPS Range	Infrastructure
< 10	Single server
10-1,000	Load balancer + 2-3 servers
1,000-10,000	Multiple servers + caching
10,000-100,000	Database sharding + CDN
100,000-1M+	Distributed systems + multiple regions

Throughput Calculation

Throughput = QPS × Average Payload Size

Example:

• 1M QPS × 1 KB average response = 1 GB/s throughput
• 1M QPS × 10 KB average response = 10 GB/s throughput

This helps you estimate network bandwidth requirements.

Interview Tips for QPS Estimation

1. Start with DAU: Most systems are estimated from daily active users
2. Apply per-user metrics: Writes per user, reads per user
3. Calculate peak: Multiply average by 2-3x
4. Consider fan-out: Popular content creates asymmetric load
5. Validate against infrastructure: Does the QPS match your architecture?

Bandwidth Formula

Bandwidth = QPS × Payload Size

Or equivalently:

Bandwidth = Throughput (requests/sec) × Avg Response Size (bytes)

Bandwidth Conversions

Unit	Value
1 Kbps	1,000 bits/sec
1 Mbps	1,000 Kbps = 10^6 bits/sec
1 Gbps	1,000 Mbps = 10^9 bits/sec
1 Tbps	1,000 Gbps = 10^12 bits/sec

Note: Network bandwidth is in bits, storage is in bytes. 1 byte = 8 bits.

Example: Bandwidth for Netflix Streaming

Given: 200M subscribers, 100M watch daily, average 2 hours/day, average 5 Mbps stream

Step 1: Concurrent viewers

Peak concurrent (20% of daily): 100M × 0.2 = 20M concurrent

Step 2: Bandwidth

20M concurrent × 5 Mbps = 100 Tbps

Step 3: With CDN (90% served from edge)

Origin bandwidth: 100 Tbps × 0.1 = 10 Tbps

Data Transfer Costs (AWS)

Direction	Cost
Inbound to AWS	Free
Outbound to Internet	$0.09/GB (first 10TB)
Between AZs	$0.01/GB
Between Regions	$0.02/GB
S3 to CloudFront	Free

Interview insight: Data transfer costs can dominate your bill. Design to minimize cross-region and cross-AZ transfer.

Bandwidth Estimation Checklist

1. Inbound bandwidth: How much data do users upload?
   • Per request × QPS
2. Outbound bandwidth: How much data do users download?
   • Per response × QPS
3. Internal bandwidth: Data transfer between services?
   • Database replication, cache updates, inter-service calls
4. CDN savings: What percentage can be cached at edge?
   • Static content: 90-99%
   • Dynamic content: 0-10%

Real Example: Bandwidth for a Chat App

Given: 50M DAU, 50 messages/user/day, 100 bytes/message average

Step 1: Message throughput

50M × 50 messages = 2.5B messages/day
2.5B / 86,400 ≈ 29,000 messages/sec

Step 2: Upload bandwidth (messages sent)

29,000 × 100 bytes = 2.9 MB/s = 23.2 Mbps

Step 3: Download bandwidth (messages received, 3x for fan-out)

29,000 × 3 × 100 bytes = 8.7 MB/s = 69.6 Mbps

Step 4: Media uploads (10% of messages include 1MB image)

29,000 × 0.1 × 1 MB = 2.9 MB/s = 23.2 Mbps

Total bandwidth: ~100 Mbps for a 50M DAU chat app.

The Estimation Framework

Use this 5-step framework for any estimation problem:

1. Clarify requirements
2. Identify key metrics
3. Make reasonable assumptions
4. Calculate step-by-step
5. Validate and sanity-check

Example: Estimate Scale for a URL Shortener (TinyURL)

Step 1: Clarify Requirements

• What's the read:write ratio? → 100:1 (mostly redirects)
• What's the retention period? → 5 years
• What's the expected traffic? → 100M URLs created per day

Step 2: Key Metrics

• Storage: How much data do we store?
• QPS: How many requests per second?
• Bandwidth: How much data transfers?

Step 3: Assumptions

• 100M new URLs per day
• Each URL: 500 bytes (original URL + short code + metadata)
• 100:1 read:write ratio
• Peak: 3x average

Step 4: Calculations

Storage per day:

100M URLs × 500 bytes = 50 GB/day

Storage per year:

50 GB/day × 365 days = 18.25 TB/year

Storage for 5 years:

18.25 TB × 5 = 91.25 TB

Write QPS (URL creation):

100M / 86,400 ≈ 1,157 QPS average
Peak (3x): 3,471 QPS

Read QPS (redirects):

100M × 100 / 86,400 ≈ 115,741 QPS average
Peak (3x): 347,222 QPS

Step 5: Validate

• 91 TB storage: Fits in a single large RDS instance or DynamoDB table
• 350K peak QPS reads: Requires caching layer (Redis/Memcached)
• Write QPS is manageable with a single database or small cluster

Architecture decisions from estimation:

• Use caching for read-heavy workload (Redis for hot URLs)
• Use a database that scales reads well (DynamoDB, Cassandra)
• Use base62 encoding for short URLs (a-z, A-Z, 0-9 = 62^7 = 3.5 trillion unique URLs)

Example: Estimate Scale for Twitter

Step 1: Clarify

• 300M DAU
• Average user: posts 2 tweets/day, views 200 tweets/day
• Average tweet: 280 chars + metadata ≈ 1 KB

Step 2: Write volume

300M × 2 = 600M tweets/day
600M / 86,400 ≈ 6,944 writes/sec average
Peak (3x): 20,833 writes/sec

Step 3: Read volume

300M × 200 = 60B timeline reads/day
60B / 86,400 ≈ 694,444 reads/sec average
Peak (3x): 2,083,333 reads/sec ≈ 2M QPS

Step 4: Storage

600M tweets × 1 KB = 600 GB/day
600 GB × 365 = 219 TB/year

Step 5: Fan-out calculation
When a celebrity (100M followers) tweets:

1 tweet → 100M timeline updates needed
At 1ms per update: 100M × 1ms = 100,000 seconds = 27.7 hours

This is impossible in real-time. Solution: Pull-based for celebrities.

Architecture decisions:

• Timeline service with caching (Redis sorted sets)
• Fan-out on write for regular users, fan-out on read for celebrities
• Sharded storage by user ID
• CDN for trending topics and media

Quick Estimation Cheat Sheet

Scenario	Quick Calculation
Users × requests/day	Total daily requests
Daily requests / 86,400	Average QPS
Average QPS × 3	Peak QPS
QPS × payload size	Bandwidth
Daily writes × retention	Storage
Daily writes × 3 (replication)	Total storage

Interview Time Management

• Clarify: 2 minutes
• Estimate: 5 minutes
• Calculate: 8 minutes
• Validate: 2 minutes
• Discuss trade-offs: 5 minutes

Total: ~20 minutes for a complete estimation.