Interview Critical : Every system design interview starts with capacity estimation. Master these calculations to ace the first 5 minutes and build credibility.
The Art of Estimation Good estimates aren’t about being exact—they’re about:
Showing structured thinking
Understanding orders of magnitude
Identifying bottlenecks early
Making reasonable assumptions
🧠 Numbers You Must Memorize Time Constants ┌─────────────────────────────────────────────────────────────────┐ │ TIME REFERENCE CARD │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Seconds in a day: 86,400 ≈ 100,000 (10^5) │ │ Seconds in a month: 2.6 million ≈ 2.5 × 10^6 │ │ Seconds in a year: 31.5 million ≈ 30 × 10^6 │ │ │ │ Quick Conversion: │ │ • 1 day = 86,400s ≈ 10^5 s │ │ • 1 week = 604,800s ≈ 6 × 10^5 s │ │ • 1 month = 2.6Ms ≈ 2.5 × 10^6 s │ │ • 1 year = 31.5Ms ≈ 3 × 10^7 s │ │ │ └─────────────────────────────────────────────────────────────────┘
Latency Numbers (Jeff Dean’s Famous List) ┌─────────────────────────────────────────────────────────────────┐ │ LATENCY NUMBERS (2024) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ L1 cache reference 0.5 ns │ │ L2 cache reference 7 ns │ │ Main memory (RAM) reference 100 ns │ │ Send 1KB over 1 Gbps network 10 μs │ │ SSD random read 100 μs (0.1 ms) │ │ Read 1 MB sequentially from memory 250 μs │ │ Round trip same datacenter 500 μs (0.5 ms) │ │ Read 1 MB sequentially from SSD 1 ms │ │ HDD seek 10 ms │ │ Read 1 MB sequentially from HDD 20 ms │ │ Send packet CA → Netherlands → CA 150 ms │ │ │ │ Rule of Thumb: │ │ • Memory: 100 ns = 10^-7 s │ │ • SSD: 100 μs = 10^-4 s │ │ • Network (same DC): 1 ms = 10^-3 s │ │ • Network (cross-continent): 100 ms = 10^-1 s │ │ │ └─────────────────────────────────────────────────────────────────┘
Data Size Reference ┌─────────────────────────────────────────────────────────────────┐ │ DATA SIZE REFERENCE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1 char (ASCII) 1 byte │ │ 1 char (UTF-8, avg) 2-3 bytes │ │ 1 Integer (32-bit) 4 bytes │ │ 1 Long/Timestamp (64-bit) 8 bytes │ │ 1 UUID 16 bytes │ │ │ │ Tweet (280 chars + metadata) ~500 bytes - 1 KB │ │ Average web page 2-5 MB │ │ Average photo (compressed) 200 KB - 2 MB │ │ Average short video (1 min) 10-50 MB │ │ HD Video (1 hour) 1-4 GB │ │ │ │ Memory Tiers: │ │ • 1 KB = 10^3 bytes │ │ • 1 MB = 10^6 bytes │ │ • 1 GB = 10^9 bytes │ │ • 1 TB = 10^12 bytes │ │ • 1 PB = 10^15 bytes │ │ │ └─────────────────────────────────────────────────────────────────┘
Capacity Numbers ┌─────────────────────────────────────────────────────────────────┐ │ SERVER CAPACITY REFERENCE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Single Web Server: │ │ • Simple API: 1,000 - 10,000 QPS │ │ • Complex API: 100 - 500 QPS │ │ • Concurrent connections: 10K - 100K │ │ │ │ Database Server: │ │ • MySQL/Postgres simple queries: 1,000 - 5,000 QPS │ │ • MySQL/Postgres complex joins: 100 - 500 QPS │ │ • Redis in-memory: 100,000+ QPS │ │ • Cassandra write-heavy: 10,000+ QPS │ │ │ │ Message Queue: │ │ • Kafka per partition: 10,000+ msg/sec │ │ • RabbitMQ per queue: 1,000 - 10,000 msg/sec │ │ │ │ Network: │ │ • 1 Gbps = 125 MB/s │ │ • 10 Gbps = 1.25 GB/s │ │ │ └─────────────────────────────────────────────────────────────────┘
Query Per Second (QPS) # Basic QPS Formula QPS = (Daily_Active_Users × Actions_Per_User_Per_Day) / Seconds_Per_Day # With Peak Factor (typically 2x-3x average) Peak_QPS = QPS × Peak_Factor # Example: Instagram-like app # 500M DAU, 20 feed views/day, Peak 3x QPS = ( 500M × 20 ) / 86 , 400 = 10B / 86 , 400 ≈ 10B / 100K = 100 , 000 QPS Peak_QPS = 100 , 000 × 3 = 300 , 000 QPS
Storage Estimation # Storage Formula Daily_Storage = Users × Actions_Per_Day × Size_Per_Action Yearly_Storage = Daily_Storage × 365 Total_Storage = Yearly_Storage × Years × Replication_Factor # Example: Twitter-like app # 200M DAU, 2 tweets/day, 500 bytes/tweet, 3x replication, 5 years Daily = 200M × 2 × 500 bytes = 200 GB Yearly = 200 GB × 365 = 73 TB Total = 73 TB × 5 × 3 = 1.1 PB
Bandwidth Estimation # Bandwidth Formula Bandwidth = QPS × Average_Response_Size # Example: Video streaming # 100K concurrent users, 5 Mbps per stream Total_Bandwidth = 100K × 5 Mbps = 500 Gbps # For a service: # 10K QPS, 100 KB average response Bandwidth = 10K × 100 KB = 1 GB / s = 8 Gbps
🎯 Step-by-Step Estimation Framework Step 1: Identify Key Metrics For any system, estimate these: 1. QPS (read and write separately) 2. Storage requirements 3. Bandwidth requirements 4. Memory requirements (for caching)
Step 2: Make Assumptions Clear "Let me make some assumptions..." Users: • Total users: X • Daily Active Users (DAU): Y% of X • Concurrent users: Z% of DAU Actions: • Actions per user per day: N • Read:Write ratio: R:W Data: • Average data size: S bytes • Retention period: T years
Step 3: Round Smartly Good rounding (powers of 10): • 86,400 → 100,000 (10^5) • 31,536,000 → 30,000,000 (3 × 10^7) • 2.6M → 2.5M or 3M Always round to make mental math easier!
🔥 Practice Problems Problem 1: Design a URL Shortener
Work through the estimation
Given assumptions:
100M new URLs per month
10:1 read-to-write ratio
5 years of data retention
Average URL: 500 bytes
Write QPS: 100M URLs / month = 100M / (30 days × 24 hours × 3600 seconds) = 100M / 2.6M seconds ≈ 100M / 3M ≈ 33 QPS Peak (3x): ~100 QPS
Read QPS: 10:1 ratio = 10 × 33 = 330 QPS Peak: ~1000 QPS
Storage (5 years): URLs = 100M × 12 months × 5 years = 6 Billion URLs Storage = 6B × 500 bytes = 3 TB With 3x replication: 9 TB
Short URL Length: 62 characters (a-z, A-Z, 0-9) 62^6 = 56 billion combinations (enough for 6B URLs) 62^7 = 3.5 trillion (very safe) → Use 7 characters for safety
Work through the estimation
Given assumptions:
500M total users
200M DAU
Average user follows 200 people
10% of users tweet daily
Average tweet: 500 bytes
Read:Write ratio: 50:1
Tweet Write QPS: Tweets/day = 200M × 10% × 2 tweets = 40M tweets Write QPS = 40M / 86,400 ≈ 40M / 100K = 400 QPS Peak: 1,200 QPS
Timeline Read QPS: Timeline views = 200M DAU × 5 views = 1B views/day Read QPS = 1B / 86,400 ≈ 1B / 100K = 10,000 QPS Peak: 30,000 QPS
Storage (5 years): Daily tweets: 40M × 500 bytes = 20 GB Yearly: 20 GB × 365 = 7.3 TB 5 years: 36.5 TB Media (10% with images): 4M images × 1 MB = 4 TB/day = 7.3 PB over 5 years
Timeline Fanout: Celebrity with 50M followers: 1 tweet → 50M timeline updates This is the "celebrity problem" → hybrid approach needed
Problem 3: Design YouTube
Work through the estimation
Given assumptions:
2B monthly active users
500M DAU watching videos
Average video watch: 5 min, 5 videos/day
500K creators uploading daily
Average video: 10 min, 100 MB (compressed)
Video Watch QPS: Views = 500M × 5 videos = 2.5B views/day View QPS = 2.5B / 86,400 ≈ 2.5B / 100K = 25,000 QPS Peak: 75,000 QPS
Video Upload QPS: Uploads = 500K / 86,400 ≈ 6 uploads/second Peak: 20 uploads/second
Storage (per year): Videos/year = 500K × 365 = 182.5M videos Storage = 182.5M × 100 MB = 18.25 PB/year Multiple resolutions (4x): ~75 PB/year
Bandwidth: Concurrent streams: 50M users Average bitrate: 5 Mbps Total: 50M × 5 Mbps = 250 Pbps Need massive CDN infrastructure!
Problem 4: Design WhatsApp
Work through the estimation
Given assumptions:
2B users total
500M DAU
Average: 50 messages/day/user
Average message: 200 bytes
5% with images (100 KB avg)
Message QPS: Messages/day = 500M × 50 = 25B messages QPS = 25B / 86,400 ≈ 25B / 100K = 250,000 QPS Peak: 750,000 QPS This is why WhatsApp uses Erlang for concurrency!
Storage (5 years): Text: 25B × 200 bytes = 5 TB/day Images: 25B × 5% × 100 KB = 125 TB/day Total: 130 TB/day = 47 PB/year = 235 PB over 5 years
Concurrent Connections: 500M DAU, 20% online at any time = 100M concurrent WebSocket connections are long-lived!
🎓 Interview Tips Do’s ✅ 1. State assumptions CLEARLY "I'll assume we have 100 million DAU..." 2. Round numbers for easier math "I'll round 86,400 to 100,000..." 3. Work through calculations out loud "So that's 100 million divided by 100,000..." 4. Sanity check your answers "Let me verify: 1 PB seems reasonable for 5 years..." 5. Identify bottlenecks early "At 300K QPS, we'll definitely need caching..."
Don’ts ❌ 1. Don't be overly precise Bad: "That's 11,574.074 QPS" Good: "About 12K QPS, let's say 15K with buffer" 2. Don't skip the estimation It shows you understand scale! 3. Don't forget peak traffic Usually 2x-3x average, more during events 4. Don't forget replication Storage usually needs 3x for fault tolerance 5. Don't confuse MB and Mb (megabytes vs megabits) 1 MB = 8 Mb
📊 Quick Reference Tables Scale Levels Scale DAU QPS Storage/Year Complexity Small 100K 10-100 100 GB Single server Medium 10M 1K-10K 10 TB Multi-server Large 100M 10K-100K 100 TB Distributed Massive 1B+ 100K+ 1 PB+ Global infrastructure
Common Patterns by QPS QPS Architecture Examples < 100 Single server Small SaaS apps 100-1K Load balancer + servers Medium businesses 1K-10K + Caching layer Social apps 10K-100K + Sharding + CDN Large platforms 100K+ Global distribution FAANG scale
Storage Growth Rates Data Type Per Item Daily (10M users) Yearly Text message 200 B 20 GB 7 TB Tweet 500 B 50 GB 18 TB Photo 500 KB 500 TB 182 PB Video (1 min) 50 MB 5 PB 1.8 EB
📝 Estimation Template Use this template in interviews:
┌─────────────────────────────────────────────────────────────────┐ │ ESTIMATION TEMPLATE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. USERS │ │ Total: _______ DAU: _______ Concurrent: _______ │ │ │ │ 2. TRAFFIC │ │ Actions/day/user: _______ │ │ Total/day: _______ │ │ QPS: _______ / 86,400 = _______ │ │ Peak QPS (×3): _______ │ │ │ │ 3. STORAGE │ │ Size per item: _______ │ │ Items/day: _______ │ │ Daily storage: _______ │ │ Yearly storage: _______ │ │ 5-year storage: _______ │ │ With replication (×3): _______ │ │ │ │ 4. BANDWIDTH │ │ Response size: _______ │ │ Bandwidth = QPS × Size = _______ │ │ │ │ 5. MEMORY (Cache) │ │ Hot data %: _______ │ │ Cache size: _______ │ │ │ │ 6. KEY INSIGHTS │ │ Read:Write ratio: _______ │ │ Primary bottleneck: _______ │ │ Scaling strategy: _______ │ │ │ └─────────────────────────────────────────────────────────────────┘