Every system design interview requires estimation. Learn the numbers, the method, and how to confidently estimate scale for any system.
Back-of-the-envelope estimation means making quick, approximate calculations to understand the scale of a system — without a calculator, without exact data, and without spending more than 2-3 minutes.
In system design interviews, interviewers ask you to estimate because they want to see:
| Power | Approximate value | Name |
|---|---|---|
| 2¹⁰ | 1 thousand | 1 KB |
| 2²⁰ | 1 million | 1 MB |
| 2³⁰ | 1 billion | 1 GB |
| 2⁴⁰ | 1 trillion | 1 TB |
| 2⁵⁰ | 1 quadrillion | 1 PB |
| Operation | Latency |
|---|---|
| L1 cache read | 1 ns |
| L2 cache read | 4 ns |
| RAM read | 100 ns |
| SSD read | 100 µs |
| Network round trip (same DC) | 500 µs |
| HDD read | 10 ms |
| Network round trip (cross-region) | 150 ms |
| Nines | Downtime/year |
|---|---|
| 99% | 3.65 days |
| 99.9% | 8.7 hours |
| 99.99% | 52 minutes |
| 99.999% | 5 minutes |
Formula:
RPS = DAU × requests_per_user_per_day / 86400
Example — Twitter-like system:
Read RPS = 300M × 100 / 86400 ≈ 350,000 RPS
Write RPS = 300M × 1 / 86400 ≈ 3,500 RPS
Rule of thumb: 80/20 rule — 80% reads, 20% writes for most social apps.
Formula:
Storage = items_per_day × item_size × retention_days
Example — Twitter tweets:
Storage = 300M × 1KB × 1825 = 547 TB ≈ 0.5 PB over 5 years
Daily: = 300M × 1KB = 300 GB/day
Formula:
Bandwidth = RPS × average_payload_size
Example — Twitter read bandwidth:
Read bandwidth = 350,000 RPS × 1KB = 350 GB/s
That's why Twitter uses CDNs aggressively — serving 350 GB/s from origin servers would be impossible.
Formula:
Servers needed = Total RPS / RPS per server
A typical web server handles ~1,000-10,000 RPS depending on workload.
For 350,000 read RPS at 10,000 RPS/server:
Servers = 350,000 / 10,000 = 35 servers (minimum)
Add 2-3x for redundancy and peak traffic → ~100 servers.
Write RPS = 100M / 86400 ≈ 1,200 RPS
Read RPS = 1,200 × 100 = 120,000 RPS
URL size = 100 bytes
Daily storage = 100M × 100B = 10 GB/day
Yearly = 10 × 365 = 3.65 TB/year
Assumptions:
- 500M DAU
- 10% upload a photo daily = 50M photos/day
- Average photo size = 1 MB (after compression)
Daily storage = 50M × 1MB = 50 TB/day
Yearly storage = 50 × 365 = 18 PB/year
| Thing | Approximate size |
|---|---|
| ASCII character | 1 byte |
| Unicode character | 2-4 bytes |
| Integer | 4 bytes |
| Long/timestamp | 8 bytes |
| UUID | 16 bytes |
| Tweet (280 chars) | ~300 bytes |
| Average webpage | ~2 MB |
| Photo (compressed) | ~300 KB - 1 MB |
| 1 minute HD video | ~100 MB |
| 1 minute 4K video | ~400 MB |
"Let me make some assumptions first:
- 100M DAU
- Read-heavy: 10:1 read-write ratio
- Average payload: 1KB
Traffic:
- Writes: 100M / 86400 ≈ 1,200 RPS
- Reads: 1,200 × 10 = 12,000 RPS
Storage:
- 1,200 writes/s × 1KB × 86400s = ~100 GB/day
- Over 5 years: ~180 TB
This tells me I need:
- Read replicas for the 10:1 read ratio
- ~2 servers for writes, ~12 for reads
- CDN for static content"