Introduction: Why Estimation Matters#
In system design interviews, you'll be asked to design systems that handle real-world scale. Interviewers want to see that you can:
- Think about scale — Not just "it works" but "it works at 1M users"
- Make informed decisions — Choose technologies based on numbers
- Identify bottlenecks — Know where the system will break
- Size infrastructure — How many servers, how much storage
- Communicate clearly — Show your reasoning
This document gives you the formulas, numbers, and techniques to estimate quickly and accurately.
The numbers to memorize (a day is about 100,000 seconds, memory is about 1,000x faster than SSD), then a Twitter-like service end to end: 200M daily users make 4 billion reads a day, about 47,000 requests a second and about 100,000 at peak; about 7 TB of new storage a day and 12.5 PB over five years; about 15 Gbps of egress that a CDN cuts to about 2.2 Gbps; and about 30 API servers, a primary with 2 read replicas and a 256 GB cache.
Chapter 1: Numbers Every Engineer Should Know#
1.1 Powers of Two#
These are essential for memory, storage, and data size calculations.
| Power | Exact value | Approximate | Name |
|---|---|---|---|
| 2^10 | 1,024 | ~1 Thousand | 1 KiB ≈ 1 KB (Kilobyte) |
| 2^20 | 1,048,576 | ~1 Million | 1 MiB ≈ 1 MB (Megabyte) |
| 2^30 | 1,073,741,824 | ~1 Billion | 1 GiB ≈ 1 GB (Gigabyte) |
| 2^40 | 1,099,511,627,776 | ~1.1 Trillion | 1 TiB ≈ 1 TB (Terabyte) |
| 2^50 | 1,125,899,906,842,624 | ~1.1 Quadrillion | 1 PiB ≈ 1 PB (Petabyte) |
Memory aids
- Every 10 powers of 2 ≈ 3 powers of 10
- 2^10 ≈ 10^3 (thousand)
- 2^20 ≈ 10^6 (million)
- 2^30 ≈ 10^9 (billion)
- Strictly, 2^10 bytes is a KiB (kibibyte) and 1 KB is 1,000 bytes; for estimation treat them as equal
Practical conversions
- 1 GB = 1,024 MB ≈ 1,000 MB (use 1,000 for estimation)
- 1 TB = 1,024 GB ≈ 1,000 GB
- 1 PB = 1,024 TB ≈ 1,000 TB
1.2 Time Conversions#
| Unit | Seconds | Round to |
|---|---|---|
| 1 minute | 60 | 60 |
| 1 hour | 3,600 | ~4,000 |
| 1 day | 86,400 | ~100,000 (10^5) |
| 1 week | 604,800 | ~600,000 |
| 1 month | 2,592,000 | ~2.5 million |
| 1 year | 31,536,000 | ~30 million (3 × 10^7) |
Key shortcuts
- 1 day ≈ 10^5 seconds (use 100,000)
- 1 year ≈ 3 × 10^7 seconds
- 1 month ≈ 2.5 × 10^6 seconds
Daily to per-second conversion
X per day ÷ 100,000 ≈ X per second
Examples:
- 100 million requests/day = 1,000 requests/second
- 1 billion requests/day = 10,000 requests/second
- 10 million requests/day = 100 requests/second
Formula
RPS = Daily Volume ÷ 86,400 (or 100,000)
100 small queries or one batch?
A page needs 100 user records from a database in the same datacenter. Option A sends 100 queries, one after another. Option B sends one batched query for all 100. Before you read the numbers below, guess how much network time each option costs.
One strong answer
- A round trip inside a datacenter is about 0.5 ms.
- Option A: 100 × 0.5 ms = ~50 ms of waiting on the network alone, before the database does any work.
- Option B: one round trip, ~0.5 ms, plus the work of the larger query.
- Round trips add up quickly, which is why "minimize network round trips" and "batch operations" are on the design list.
1.3 Latency Numbers Every Programmer Should Know#
These numbers were popularized by Jeff Dean's famous talk (circa 2009-2012; the SSD rows were added in later versions). Absolute values have shifted with newer hardware (NVMe SSDs are faster), but the ratios are what matter for system performance.
| Operation | Time | Scale |
|---|---|---|
| L1 cache reference | 0.5 ns | | |
| Branch mispredict | 5 ns | | |
| L2 cache reference | 7 ns | | |
| Mutex lock/unlock | 25 ns | | |
| Main memory reference | 100 ns | |= |
| Compress 1KB with Snappy | 3,000 ns | |=== |
| Send 1 KB over 1 Gbps network | 10,000 ns | |==== |
| Read 4 KB randomly from SSD | 150,000 ns | |====== |
| Read 1 MB sequentially from memory | 250,000 ns | |======= |
| Round trip within same datacenter | 500,000 ns | |======== |
| Read 1 MB sequentially from SSD | 1,000,000 ns | |========= |
| HDD seek | 10,000,000 ns | |long bar |
| Read 1 MB sequentially from HDD | 20,000,000 ns | |
| Send packet CA → Netherlands → CA | 150,000,000 ns |
1 KB over 1 Gbps is 8 μs of pure transmission (8,000 bits ÷ 10^9 bits/s); the 10 μs figure rounds up for framing and protocol overhead, so read it as ≈ 8–10 μs.
Human-readable scale
- L1 cache: 0.5 ns
- Main memory: 100 ns = 200x slower than L1
- SSD random read: 150 μs = 150,000 ns = 1,500x slower than memory
- HDD seek: 10 ms = 10,000,000 ns = 67x slower than SSD
- Network round trip (datacenter): 0.5 ms
- Network round trip (cross-continent): 150 ms
Key insights
- Memory is ~1000x faster than SSD for random access (1,500x in the table; only ~4x for 1 MB sequential reads)
- SSD is ~70x faster than HDD for random reads (only ~20x for 1 MB sequential reads)
- Network within datacenter is fast (~0.5ms)
- Cross-continent network is slow (~150ms)
- Sequential reads are MUCH faster than random reads
Design implications
- Cache aggressively (memory >> disk)
- Minimize network round trips
- Batch operations when possible
- Use CDN for global users
- Prefer SSDs over HDDs for performance
- Use sequential access patterns when possible
📚 Source: Jeff Dean's "Numbers Everyone Should Know" - https://brenocon.com/dean_perf.html (the original 2009-era slide, with older figures such as mutex 100 ns, Zippy 10 μs, disk read 30 ms/MB). The table above uses the later widely circulated update: https://gist.github.com/jboner/2841832
On one linear scale, main memory (100 ns) is 200 times an L1 cache reference (0.5 ns), a random 4 KB SSD read (150 μs) is 1,500 times memory, an HDD seek (10 ms) is 67 times an SSD read, a datacenter round trip is 0.5 ms and a packet CA → Netherlands → CA takes 150 ms.
1.4 Typical Data Sizes#
Text data
| Item | Size |
|---|---|
| Character (ASCII) | 1 byte |
| Character (UTF-8, average) | 1-4 bytes |
| UUID | 36 bytes (string) / 16 bytes (bin) |
| Email address | ~30 bytes |
| URL | ~100 bytes |
| Tweet (text + metadata) | ~300 bytes on average (~500 bytes for a full 280 characters) |
| Typical JSON API response | 2-10 KB |
| Average email | 50-100 KB |
| Average web page (HTML + assets) | 2-3 MB |
Media
| Item | Size |
|---|---|
| Favicon | ~1 KB |
| Thumbnail image | 5-10 KB |
| Profile picture (small) | 50-100 KB |
| Regular photo (compressed) | 200 KB - 2 MB |
| High-res photo | 5-10 MB |
| 1 minute of video (720p, phone recording) | ~50 MB |
| 1 minute of video (1080p, phone recording) | ~60-100 MB |
| 1 minute of video (4K, phone recording) | ~350 MB |
| 1 minute of streamed video (1080p, ~3-5 Mbps) | ~25-40 MB |
| 1 minute of audio (MP3) | ~1 MB |
Database records (typical)
| Record type | Size |
|---|---|
| User profile (basic) | 500 bytes - 1 KB |
| Product listing | 1-5 KB |
| Order record | 500 bytes - 1 KB |
| Log entry | 200-500 bytes |
| Search index entry | 200 bytes |
| Session data | 1-2 KB |
Rule of thumb: When in doubt, estimate 1 KB per record.
1.5 Throughput Reference Numbers#
Network bandwidth
| Connection type | Speed | Data/second |
|---|---|---|
| Home broadband | 100 Mbps | 12.5 MB/s |
| Home fiber | 1 Gbps | 125 MB/s |
| AWS within Availability Zone | 10-25 Gbps | 1-3 GB/s |
| Datacenter backbone | 100+ Gbps | 12+ GB/s |
Formula: Gbps ÷ 8 = GB/s (bits to bytes)
Database throughput
| Database | Operations/second (approximate) |
|---|---|
| PostgreSQL (single) | 10,000-50,000 queries/sec |
| MySQL (single) | 10,000-50,000 queries/sec |
| Redis (single) | 100,000+ ops/sec |
| Cassandra (per node) | 10,000-50,000 writes/sec |
| MongoDB (single) | 10,000-30,000 ops/sec |
| DynamoDB (on-demand) | Scales out (per-partition and account limits apply) |
Note: Actual throughput depends heavily on:
- Query complexity
- Data size
- Hardware specs
- Network latency
Web server throughput
| Server type | Requests/second (approximate) |
|---|---|
| Node.js (simple API) | 5,000-10,000 req/sec |
| Go (simple API) | 30,000-50,000 req/sec |
| Nginx (static files) | 50,000-100,000 req/sec |
| Node.js (complex logic) | 1,000-3,000 req/sec |
| Python/Django | 500-2,000 req/sec |
Conservative estimate: 5,000 req/sec per server for simple APIs
Numbers every engineer should know
Q1/3 A service handles 50 million requests per day. Using the day-is-about-100,000-seconds shortcut, what is the average RPS?
Answer & explanation
Answer: A
50,000,000 / 100,000 = 500 RPS. The exact divisor (86,400) gives about 580, close enough for sizing. 5,000 RPS is what you get if you divide by 10,000 by mistake; count the zeros.
Q2/3 A request handler makes 4 sequential calls to a service on another continent. What does that mean for latency, and what is the fix?
Answer & explanation
Answer: B
Each cross-continent round trip is about 150ms, so 4 in a row cost about 600ms before any work is done. SSDs speed up disk reads, not the speed of light; the fix is fewer round trips or shorter distances.
Q3/3 Your instance has a 10 Gbps network link. Roughly how much data can it push per second?
Answer & explanation
Answer: C
Network speeds are in bits; divide by 8 for bytes: 10 Gbps / 8 = 1.25 GB/s. Reading Gbps as GB/s overstates capacity by 8x, the "wrong units" pitfall.
Chapter 2: The Estimation Framework#
2.1 The Four Types of Estimates#
Every system design requires estimating these four things:
- Traffic estimates — Key question: How many requests will we handle?
- Daily/monthly active users (DAU/MAU)
- Requests per second (RPS)
- Read vs write ratio
- Peak vs average traffic
- Storage estimates — Key question: How much data will we store?
- Data per user/object
- Total storage needed (now and future)
- Growth rate
- Retention period
- Bandwidth estimates — Key question: How much data will flow through the system?
- Ingress (data coming in)
- Egress (data going out)
- Peak bandwidth requirements
- Infrastructure estimates — Key question: What infrastructure do we need?
- Number of servers
- Database sizing and replication
- Cache memory requirements
Estimate it: 10 million users, 55 actions each
An app has 10 million daily active users. Each one posts 5 times and reads 50 times a day. What is the average requests per second, the peak at a 2× factor, and the split between reads and writes?
One strong answer
- Daily: 10 million × 55 = 550 million actions.
- Average: 550 million ÷ 100,000 ≈ 5,500 RPS. Peak (2×): 11,000 RPS.
- Split: 50 reads to 5 writes is 10:1, so ~5,000 read RPS and ~500 write RPS.
- Size the servers for the peak. The read/write split tells you whether caching or the write path matters more.
2.2 Traffic Estimation#
The Formula#
Step 1: Calculate daily volume
Daily Actions = DAU × Actions per User
Example:
- DAU: 10 million
- Actions per user: 5 posts + 50 reads = 55 actions
- Daily actions: 10M × 55 = 550 million
Step 2: Convert to requests per second (RPS)
RPS = Daily Actions ÷ 86,400 (seconds per day)
Shortcut: Daily / 100,000 ≈ RPS
Example:
- 550 million / 100,000 = 5,500 RPS
Step 3: Calculate peak RPS
Peak RPS = Average RPS × Peak Factor
Peak factors:
- Normal apps: 2x average
- Social/viral: 3x average
- Flash sales/events: 5-10x average
Example:
- Average: 5,500 RPS
- Peak (2x): 11,000 RPS
Step 4: Split by read/write
If ratio is 10:1 (reads:writes):
- Total: 5,500 RPS
- Reads: 5,500 × 10/11 = 5,000 RPS
- Writes: 5,500 × 1/11 = 500 RPS
Common ratios:
- Read-heavy (social media): 100:1 to 1000:1
- Mixed (e-commerce): 10:1 to 100:1
- Write-heavy (logging): 1:1 to 1:10
Worked Example: Twitter-like Service#
Given
- 500 million monthly active users (MAU)
- 200 million daily active users (DAU)
- Each user views 20 tweets per day
- Each user posts 0.5 tweets per day
Calculate
- Reads per day: 200M users × 20 views = 4,000,000,000 reads/day = 4 billion reads/day
- Writes per day: 200M users × 0.5 posts = 100,000,000 writes/day = 100 million writes/day
- Read/Write ratio: 4B / 100M = 40:1
- Reads per second: 4B / 100,000 = 40,000 read RPS (More precise: 4B / 86,400 = 46,296 RPS)
- Writes per second: 100M / 100,000 = 1,000 write RPS (More precise: 100M / 86,400 = 1,157 RPS)
- Total: ~47,000 RPS average
- Peak (2x): ~94,000 RPS
Interview phrase
"With 200M DAU viewing 20 tweets each, that's 4 billion reads per day, or about 46,000 reads per second. Writes are much lower at about 1,000 per second. Peak would be roughly double, so we need to design for ~100,000 RPS."
Should the images live in the database too?
In the Twitter-like example, 100 million tweets a day at 300 bytes each sit in a database kept as 3 copies. A tenth of tweets carry a 200 KB image and a hundredth carry a 5 MB video. Would you store the images and videos in that same database? Estimate before you decide.
One strong answer
- Text: 30 GB a day → about 165 TB over 5 years at 3 copies.
- Media: 2 TB + 5 TB = ~7 TB a day → ~12.8 PB over 5 years. Three database copies of that would be ~38 PB.
- So no. Media is 99%+ of the bytes. It goes to object storage (S3), which replicates internally, and the database keeps the small text rows.
2.3 Storage Estimation#
The Formula#
- Basic formula: Storage = Number of Objects × Size per Object × Retention Period
- Daily growth: Daily Growth = New Objects per Day × Size per Object
- Yearly storage: Yearly Storage = Daily Growth × 365
- With replication: Total Storage = Raw Storage × Replication Factor
Common replication factors
- Databases: 3x (1 primary + 2 replicas)
- Object storage (S3): Already replicated (built-in)
- Kafka: 3x (3 replicas per partition)
Don't forget
- Indexes: Add 20-30% for database indexes
- Logs: Often as large as main data
- Backups: Often 2-3x for backup retention
Worked Example: Twitter-like Service#
Given
- 100 million new tweets per day
- Average tweet: 300 bytes (text + metadata)
- 10% of tweets have images (average 200 KB)
- 1% of tweets have videos (average 5 MB)
- Retention: Keep everything (5 years for estimation)
Calculate
- Text storage (per day): 100M tweets × 300 bytes = 30 GB/day
- Image storage (per day): 100M × 10% = 10M images; 10M × 200 KB = 2 TB/day
- Video storage (per day): 100M × 1% = 1M videos; 1M × 5 MB = 5 TB/day
- Total daily: 30 GB + 2 TB + 5 TB ≈ 7 TB/day (Media dominates storage!)
- Yearly: 7 TB × 365 = 2.5 PB/year
- 5-year storage: 2.5 PB × 5 = 12.5 PB
With replication (3x for database, S3 handles media)
- Text DB: 30 GB/day × 365 × 5 × 3 = 165 TB
- Media (S3): 7 TB × 365 × 5 = 12.8 PB (S3 replicates internally)
Summary
"We'll need about 7 TB of new storage per day, or 2.5 PB per year. Over 5 years, that's roughly 13 PB. Media is 99%+ of storage."
What breaks if every image leaves from the origin?
The Twitter-like service serves ~46,000 reads a second. Each read is a 2 KB response, and 20% of reads also send a 200 KB image. If every byte leaves from your own origin servers with no CDN, how much egress is that on average and at a 2× peak? Where do most of the bytes come from?
One strong answer
- Text: 46,000 × 2 KB ≈ 92 MB/s.
- Images: 46,000 × 0.2 × 200 KB ≈ 1,840 MB/s, about 95% of the total.
- Total: ~1.9 GB/s ≈ 15 Gbps on average, ~30 Gbps at peak, all from your origin.
- Because the images make up most of the bytes, a CDN that serves 90% of image requests cuts origin egress to about 2.2 Gbps.
2.4 Bandwidth Estimation#
The Formula#
- Ingress (data coming IN): Ingress = Write RPS × Average Request Size — typically smaller (just the data being uploaded)
- Egress (data going OUT): Egress = Read RPS × Average Response Size — usually larger (responses include more data)
Converting units
- MB/s × 8 = Mbps (megabits per second)
- GB/s × 8 = Gbps (gigabits per second)
- Example: 100 MB/s = 800 Mbps = 0.8 Gbps
Worked Example: Twitter-like Service#
Given (from traffic estimation)
- Read RPS: 46,000
- Write RPS: 1,150
- Tweet read response: 2 KB (tweet + user info)
- Tweet write request: 300 bytes
- 10% of new tweets include an image (200 KB), as in the storage estimate
- 20% of read responses include an image (200 KB): image tweets get more views than their 10% share of posts
Ingress (writes coming in)
- 1,150 writes/sec × 300 bytes = 345 KB/sec
- With 10% images: 1,150 × 0.1 × 200 KB = 23 MB/sec
- Total ingress: ~24 MB/sec = ~200 Mbps
Egress (reads going out)
- Text only: 46,000 × 2 KB = 92 MB/sec
- With images: 46,000 × 0.2 × 200 KB = 1,840 MB/sec
- Total egress: ~1.9 GB/sec = ~15 Gbps
Peak (2x)
- Ingress peak: ~400 Mbps
- Egress peak: ~30 Gbps
Note: This is why CDN is essential! CDN handles most of the 30 Gbps egress for images. Origin servers see much less.
With CDN (90% cache hit rate for images)
- Origin egress: 92 MB/sec + (1,840 × 0.1) = ~280 MB/sec = ~2.2 Gbps (much more manageable)
Why plan for 70% and not 100%?
Peak traffic is 100,000 RPS and each simple API server handles 5,000 RPS. You could run 20 servers flat out, or plan for 70% utilization. What does the headroom cost, and what does it buy you?
One strong answer
- At 100%: 100,000 ÷ 5,000 = 20 servers, with no room for anything to go wrong.
- At 70%: 100,000 ÷ (5,000 × 0.7) ≈ 29 servers, about 45% more machines.
- What it buys: a spike above the estimate or a failed server lands on machines that still have spare capacity. At 100%, either one overloads the pool at the busiest moment.
2.5 Infrastructure Estimation#
Server Sizing#
Web/API servers
Servers = Peak RPS ÷ (RPS per Server × Utilization Target)
Guidelines:
- Simple API (CRUD): 5,000-10,000 RPS per server
- Complex logic: 1,000-3,000 RPS per server
- CPU-intensive: 100-500 RPS per server
- Target utilization: 70% (leave headroom)
Example:
- Peak RPS: 100,000
- RPS per server: 5,000
- Utilization: 70%
- Servers = 100,000 / (5,000 × 0.7) = 29 servers — round up to 30-35 for availability
Database sizing
For reads (read replicas): Read Replicas = Read RPS ÷ Queries per DB (30,000)
For writes: Usually single primary (shard if > 10,000 writes/sec)
Example:
- Read RPS: 46,000
- Replicas: 46,000 / 30,000 = 2 read replicas
- Total: 1 primary + 2 replicas = 3 DB servers
Cache sizing
Memory = Hot Data Size
Rules of thumb:
- Cache 20% of data (80/20 rule)
- Or cache last N hours/days of activity
- Aim for 90%+ cache hit rate
Example:
- Daily new data: 30 GB (text only)
- Cache last 7 days: 210 GB
- Use 256 GB Redis cluster
Traffic, storage and server sizing
Q1/3 A concert-ticketing app averages 2,000 RPS, but sales open at fixed times. What peak should you design for?
Answer & explanation
Answer: B
The lesson's peak factors are 2x for normal apps, 3x for viral social apps and 5-10x for flash sales and events. 2x is right for a steady app, but ticket drops are flash-sale traffic, so 2x leaves you badly under-provisioned.
Q2/3 In the Twitter storage estimate, text is about 30 GB/day while images and video add about 7 TB/day. What design conclusion follows?
Answer & explanation
Answer: C
Media is 99%+ of the bytes, so it goes to S3 (already replicated internally) while text stays in a 3x-replicated DB of about 165 TB over 5 years. 3x replication on 30 GB/day is still tiny next to 7 TB/day of media.
Q3/3 Peak traffic is 50,000 RPS, a simple API server handles 5,000 RPS, and you target 70% utilization. About how many servers do you need?
Answer & explanation
Answer: A
50,000 / (5,000 x 0.7) = 50,000 / 3,500, about 14.3, so round up to roughly 15 (more for redundancy). 10 is the answer if you forget the 70% headroom, which leaves no room for spikes or a failed server.
Chapter 3: Quick Reference Formulas#
3.1 The Cheat Sheet#
Traffic
- RPS = Daily requests / 100,000
- Peak RPS = Average RPS × 2 (or 3 for viral apps)
Storage
- Daily storage = New objects × Size per object
- Yearly storage = Daily × 365
- With replication = Raw × 3
Bandwidth
- Egress = Read RPS × Response size
- Ingress = Write RPS × Request size
- MB/s × 8 = Mbps
Servers
- API servers = Peak RPS / 5,000 / 0.7
- DB replicas = Read RPS / 30,000
- Cache = Hot data size (20% of total or N days)
Common values
| Quantity | Value |
|---|---|
| 1 day | 100,000 seconds (approximately) |
| 1 year | 30 million seconds (approximately) |
| Typical API response | 2-10 KB |
| Typical DB record | 500 bytes - 1 KB |
| Image | 200 KB - 2 MB |
| Server capacity | 5,000 simple requests/sec |
| DB capacity | 30,000 queries/sec |
| Redis capacity | 100,000 ops/sec |
3.2 Common Estimation Templates#
Social media template
Inputs:
- MAU: _______
- DAU: _______ (usually 20-40% of MAU)
- Posts per user per day: _______
- Views per user per day: _______
- % posts with media: _______
Calculations:
- Write RPS = DAU × Posts / 100,000
- Read RPS = DAU × Views / 100,000
- Storage/day = DAU × Posts × (text size + media% × media size)
- API servers = (Read + Write RPS) × 2 / 5,000 / 0.7
E-commerce template
Inputs:
- Daily visitors: _______
- Pages per visit: _______
- Conversion rate: _______ (1-3%)
- Products in catalog: _______
Calculations:
- Page views/day = Visitors × Pages
- Orders/day = Visitors × Conversion rate
- Read RPS = Page views / 100,000
- Product catalog size = Products × 5 KB
URL shortener template
Inputs:
- New URLs per month: _______
- Read:Write ratio: _______ (usually 100:1)
- URL record size: _______ (~500 bytes)
Calculations:
- Write RPS = URLs/month / 2.5M (seconds/month)
- Read RPS = Write RPS × ratio
- Storage = URLs × 500 bytes × retention years
- Short code length = log₆₂(total URLs needed)
- 6 chars = 56B combinations, 7 chars = 3.5T
Chapter 4: Interview Tips#
4.1 How to Present Estimates#
Do
- State assumptions clearly FIRST
"Let me assume we have 100 million DAU..." - Show your math step by step
"100 million users × 10 posts = 1 billion posts per day" - Round to nice numbers
"That's about 12,000 per second, let's call it 10K RPS" - Convert to useful units
"10 KB per request × 10K RPS = 100 MB/sec" - Sanity check your results
"10 PB seems large, but large video platforms store far more than that, so this is reasonable" - Explain implications
"At 100K RPS, we'll need about 30 API servers and should definitely use a caching layer"
Don't
- Spend more than 5 minutes on estimation
Get to approximate numbers and move on - Use overly precise numbers
"12,453 requests per second" → Just say "~12,000" or "~10K" - Forget peak traffic
Always mention peak is 2-3x average - Skip the "so what"
Numbers should lead to design decisions
4.2 Common Pitfalls#
| Pitfall | Wrong | Right |
|---|---|---|
| 1. Forgetting peak traffic | "We get 10,000 RPS" → designs for 10K | "Average is 10K RPS, peak is 20-30K" → designs for 30K |
| 2. Ignoring growth | "We need 100 GB storage" | "We need 100 GB now, 1 TB in a year at 10x growth" |
| 3. Forgetting replication | "Database needs 500 GB" | "500 GB × 3 replicas = 1.5 TB total" |
| 4. Underestimating media | "Posts are 1 KB, so storage is small" | "Text is 1 KB, but 20% have 500 KB images = 100x more storage" |
| 5. Overlooking bandwidth | Calculate storage but forget egress costs | "30 Gbps egress = need CDN to reduce costs" |
| 6. Wrong units | Mixing MB and Mb (megabytes vs megabits) | Always clarify: "100 megabytes per second" |
4.3 Quick Mental Math Tricks#
Multiplying large numbers
- 100 million × 10 = 1 billion
- 100 million × 100 = 10 billion
- 1 billion × 1000 = 1 trillion
Trick: Count zeros, add exponents — 10^8 × 10^2 = 10^10 = 10 billion
Daily to per-second
Divide by 100,000 (or 10^5)
- 1 billion/day = 10,000/second
- 100 million/day = 1,000/second
- 10 million/day = 100/second
Percentages
| Percent | Operation |
|---|---|
| 1% | ÷ 100 |
| 10% | ÷ 10 |
| 20% | ÷ 5 |
| 25% | ÷ 4 |
| 50% | ÷ 2 |
Storage conversions
- 1000 KB = 1 MB
- 1000 MB = 1 GB
- 1000 GB = 1 TB
- 1000 TB = 1 PB
- 1 million KB = 1 GB
- 1 billion KB = 1 TB
Presenting estimates and avoiding pitfalls
Q1/3 You estimate a database at 500 GB. Which pitfall is most likely missing from that number?
Answer & explanation
Answer: A
Each copy stores the full data, so a 1-primary-plus-2-replica setup needs about 3x the raw size (plus 20-30% for indexes). Peak traffic drives server and bandwidth sizing, not how many bytes sit on disk.
Q2/3 Posts are 1 KB of text and 20% include a 500 KB image. Why is "storage is small, posts are 1 KB" wrong?
Answer & explanation
Answer: B
20% x 500 KB = 100 KB per post on average, so media, not text, sets the storage budget. Replication multiplies everything by about 3, not 100; the gap comes from the media.
Q3/3 You have just worked out about 30 Gbps of image egress at peak. What is the strongest next sentence in an interview?
Answer & explanation
Answer: C
Numbers should lead to design decisions; that is the "so what" step. Here it is a CDN in front of image storage. Adding precision or more estimates burns interview time without changing the design.
Chapter 5: Practice Problems#
5.1 Practice: Instagram#
Problem
Estimate the infrastructure needs for Instagram-like app
Given
- 1 billion MAU
- 500 million DAU
- Each user views 50 photos per day
- Each user posts 1 photo per week
- Average photo: 2 MB
- Keep photos forever
Calculate
- Photo views per second
- Photo uploads per second
- Daily storage growth
- 5-year storage
- Egress bandwidth
- Number of API servers needed
TRY IT YOURSELF FIRST!
Solution
- 1. Photo views/second: 500M DAU × 50 views = 25 billion views/day; 25B / 100,000 = 250,000 read RPS
- 2. Photo uploads/second: 500M DAU / 7 (weekly) = 71 million uploads/day; 71M / 100,000 = 710 write RPS
- 3. Daily storage: 71M photos × 2 MB = 142 TB/day
- 4. 5-year storage: 142 TB × 365 × 5 = 259 PB (This is just raw photos - thumbnails add more)
- 5. Egress bandwidth: 250,000 RPS × 2 MB = 500 GB/sec = 4 Tbps (This is why CDN is ESSENTIAL); with 95% CDN hit rate: 25 GB/sec origin traffic
- 6. API servers: Peak: 250,000 × 2 = 500,000 RPS; Servers: 500,000 / 5,000 / 0.7 = 143 servers; round to: 150 API servers (more for redundancy)
5.2 Practice: YouTube#
Problem
Estimate infrastructure for YouTube-like video platform
Given
- 2 billion MAU
- 1 billion DAU
- Average watch time: 1 hour/day
- 500 hours of video uploaded per minute
- Average video: 5 minutes, stored at multiple resolutions
- Resolutions: 360p (200MB/hr), 720p (500MB/hr), 1080p (1.5GB/hr)
Calculate
- Video streaming bandwidth
- Upload volume per day
- Storage per year
- CDN requirements
Hints
- Focus on streaming bandwidth (it's massive)
- Consider multiple resolutions
- CDN is absolutely essential
TRY IT YOURSELF!
Summary#
Memorize these numbers
- 1 day = 86,400 seconds ≈ 100,000 for estimation
- 1 year ≈ 30 million seconds
- L1 cache: 0.5ns, Memory: 100ns, SSD: 150μs, HDD: 10ms
- Datacenter RTT: 0.5ms, Cross-continent: 150ms
The four estimates
- Traffic (RPS = daily / 100,000, peak = 2-3x)
- Storage (objects × size × retention × replication)
- Bandwidth (RPS × payload size)
- Infrastructure (RPS / capacity per server)
Key formulas
- RPS = Daily actions / 100,000
- Peak = Average × 2 (or 3)
- Servers = Peak RPS / 5,000 / 0.7
- DB replicas = Read RPS / 30,000
Interview tips
- State assumptions clearly
- Show your math
- Round to nice numbers
- Sanity check results
- Connect numbers to design decisions
- Don't spend more than 5 minutes
Further Reading#
References#
- Read
Jeff Dean's Latency Numbers: https://brenocon.com/dean_perf.html
- Read
Latency Numbers Interactive: https://colin-scott.github.io/personal_website/research/interactive_latency.html
- Read
System Design Primer - Back of Envelope: https://github.com/donnemartin/system-design-primer#back-of-the-envelope-calculations
Books#
- Designing Data-Intensive Applications - Martin Kleppmann (Chapter 1)
- System Design Interview - Alex Xu (Chapter 2)
Practice#
- Pramp: Free mock interviews
- Interviewing.io: Practice with real interviewers
- LeetCode Discuss: System design questions
Week 0 So Far#
You now have the core of the foundation for the weeks ahead:
Part 1 System Design Framework (HLD/LLD, interview structure) Part 2: Infrastructure Building Blocks (all the components) Part 3: Back-of-the-Envelope Estimation (sizing systems)
Next Parts 4-8 cover networking, operating systems, terminology/theory, API design and databases.
this lesson in shorts · 2
play them all →One idea from this lesson in about a minute each, made for your phone.
Go deeper · reading trail
all reading →Real write-ups from the teams that built these systems. Each opens on the publisher's site in a new tab.
Non-Abstract Large System Design
Salim Virji, James Youngman et al. · 2018- What
- A worked design exercise from Google's SRE workbook that sizes a real system step by step.
- Key idea
- Start with a design that works on one machine, then estimate QPS, storage, bandwidth and machine counts to see where it breaks and what it costs.
- Why here
- It is the estimation method of this part done in full: traffic, storage, bandwidth and infrastructure estimates driving each design decision.
Designs, Lessons and Advice from Building Large Distributed Systems
Jeff Dean · 2009- What
- Slides from Jeff Dean's keynote on how Google builds large systems, including the original 'numbers everyone should know'.
- Key idea
- Knowing rough costs (memory reference, disk seek, datacenter round trip) lets you estimate a design's performance before building it.
- Why here
- The source of the latency table this part teaches, plus examples of using those numbers to choose between designs.
Napkin Math
Simon Eskildsen- What
- An open repository of measured throughput and latency numbers for memory, disks, networks and databases, with estimation techniques.
- Key idea
- Benchmarks on current hardware give base rates you can multiply out to check whether a design's numbers are plausible.
- Why here
- An up-to-date companion to the throughput reference numbers and estimation templates in this part.
New lessons by email
New lessons, side quests and case files as they ship, at most once a week. No spam, unsubscribe anytime.
Discussion · …
Public: everyone reading this lesson sees comments. Be kind and keep it on the material.