Chapter 3: Back-of-Envelope Estimation
Before designing anything, estimate the scale. These rough calculations tell you whether you need 1 server or 1000, whether data fits in RAM or needs distributed storage.
Numbers Every Engineer Should Know
| Operation | Time |
|---|---|
| L1 cache reference | 1 ns |
| L2 cache reference | 4 ns |
| RAM reference | 100 ns |
| Send 1KB over 1 Gbps network | 10 μs |
| SSD random read | 100 μs |
| Read 1 MB sequentially from SSD | 1 ms |
| HDD seek | 10 ms |
| Read 1 MB sequentially from HDD | 20 ms |
| Round trip within same datacenter | 0.5 ms |
| Round trip US coast to coast | 40 ms |
| Round trip US to Europe | 80 ms |
Power of 2 Quick Reference
| Power | Exact | Approx | Name |
|---|---|---|---|
| 2¹⁰ | 1,024 | 1 Thousand | 1 KB |
| 2²⁰ | 1,048,576 | 1 Million | 1 MB |
| 2³⁰ | 1,073,741,824 | 1 Billion | 1 GB |
| 2⁴⁰ | ~1.1 Trillion | 1 Trillion | 1 TB |
Handy Conversion
// Time conversions for estimation:
1 day = 86,400 seconds ≈ 10⁵ seconds
1 month = 2.6M seconds ≈ 2.5 × 10⁶ seconds
1 year = 31.5M seconds ≈ 3 × 10⁷ seconds
// QPS from daily/monthly numbers:
1M requests/day = 1M / 86400 ≈ 12 QPS
100M requests/day = 100M / 86400 ≈ 1200 QPS
1B requests/day = 1B / 86400 ≈ 12,000 QPS
// Peak is typically 2-3x average:
Average 1200 QPS → Peak ~3000 QPSEstimation Example: Twitter-like System
// Given:
// 300M monthly active users (MAU)
// 50% use daily (DAU = 150M)
// Each user posts 2 tweets/day
// Each user reads 100 tweets/day (timeline)
// Average tweet = 300 bytes (text + metadata)
// 10% of tweets have media (average 1MB)
// Write QPS:
// 150M users × 2 tweets/day = 300M tweets/day
// 300M / 86400 ≈ 3500 writes/sec
// Peak: ~10,000 writes/sec
// Read QPS:
// 150M × 100 reads/day = 15B reads/day
// 15B / 86400 ≈ 175,000 reads/sec
// Read:Write ratio = 50:1 → heavily read-optimized
// Storage (text, per day):
// 300M tweets × 300B = 90GB/day
// Per year: 90GB × 365 = 33TB/year
// Storage (media, per day):
// 300M × 10% × 1MB = 30TB/day (!)
// Per year: 30TB × 365 = 11PB/year → need object storage (S3)
// Bandwidth:
// 175K reads/sec × 300B = 52MB/sec (text, trivial)
// Media serving dominates bandwidthServer Capacity Rules of Thumb
| Resource | Single Server Capacity |
|---|---|
| Web server (stateless) | ~10K-50K concurrent connections |
| PostgreSQL | ~5K-10K QPS (depends on query complexity) |
| Redis | ~100K-500K ops/sec |
| Kafka (per broker) | ~100K-200K messages/sec |
| RAM | 64-512 GB typical server |
| SSD | 1-10 TB typical |
| Network | 1-25 Gbps |
💡 The Point of Estimation
You don't need exact numbers. You need to know the order of magnitude. Is it 10 servers or 10,000? Does data fit in RAM (< 500GB) or need distributed storage (> 10TB)? Can one database handle it or do you need sharding? That's what estimation tells you.
Availability Numbers
| Availability | Downtime/Year | Downtime/Month |
|---|---|---|
| 99% (two nines) | 3.65 days | 7.3 hours |
| 99.9% (three nines) | 8.76 hours | 43.8 minutes |
| 99.99% (four nines) | 52.6 minutes | 4.4 minutes |
| 99.999% (five nines) | 5.26 minutes | 26.3 seconds |
Key Takeaways
- Memorize latency numbers (RAM=100ns, SSD=100μs, network=0.5ms)
- Convert monthly/daily numbers to QPS: divide by 86400 (seconds/day)
- Peak = 2-3× average QPS
- Estimation tells you order of magnitude: 1 server vs 100 vs 10,000
- Storage: text is small (GBs), media is huge (TBs/PBs)
- Read:write ratio drives architecture (caching, replicas, etc.)