Estimation cheat sheet: numbers every engineer should know
The latency numbers, storage conversion rules, and throughput estimates you need for back-of-envelope calculations in system design interviews. Plus a worked example showing how these numbers combine to guide design decisions.
Latency Numbers (Approximations)
These are from Jeff Dean's classic "Numbers Every Engineer Should Know," updated for modern hardware:
| Operation | Approximate Latency |
|---|---|
| L1 cache reference | 1 ns |
| L2 cache reference | 4 ns |
| Branch misprediction | 5 ns |
| L3 cache reference | 40 ns |
| Mutex lock/unlock | 25 ns |
| Main memory reference | 100 ns |
| Compress 1KB with Snappy | 3 µs |
| Read 1MB sequentially from memory | 10 µs |
| Read 1MB from SSD (NVMe) | 100 µs |
| Roundtrip within same datacenter | 500 µs |
| Read 1MB sequentially from SSD | 1 ms |
| HDD seek | 4 ms |
| Read 1MB sequentially from HDD | 20 ms |
| Packet roundtrip US East to West Coast | 40 ms |
| Packet roundtrip US to Europe | 80 ms |
| Packet roundtrip US to Australia | 150 ms |
| TCP connection establishment | 1× RTT |
| TLS handshake (resumption) | 1× RTT |
| TLS handshake (full) | 2× RTT |
Key ratios to memorize:
- Memory is ~1000× faster than SSD for sequential reads
- SSD random I/O is ~100× faster than HDD random I/O
- Same-datacenter network is ~5× faster than cross-US network
Powers of 2 (Storage Reference)
| Power | Exact | Approx | Common name |
|---|---|---|---|
| 2^10 | 1,024 | 1 thousand | 1 KB |
| 2^20 | 1,048,576 | 1 million | 1 MB |
| 2^30 | 1,073,741,824 | 1 billion | 1 GB |
| 2^40 | ~1.1 trillion | 1 trillion | 1 TB |
| 2^50 | ~1.1 quadrillion | 1 quadrillion | 1 PB |
Day to seconds: 86,400 ≈ 10^5 = 100K seconds/day
In interviews, round aggressively:
- 1 billion ≈ 10^9
- 1 million ≈ 10^6
- 1 trillion ≈ 10^12
Throughput Rules of Thumb
Database:
- A single PostgreSQL primary: ~5k-20k reads/sec (depends on query complexity and index efficiency)
- A single PostgreSQL primary: ~1k-5k writes/sec (depends on WAL flush settings)
- A Redis instance: ~100k-500k ops/sec
Network:
- Typical server NIC: 1-10 Gbps = 125 MB/s to 1.25 GB/s per second
- HTTP overhead per request: ~300 bytes minimum (headers)
- gRPC overhead: less than HTTP/1.1 (binary framing, header compression)
Storage:
- HDD sequential: ~200 MB/s
- SSD (SATA): ~500 MB/s
- SSD (NVMe): ~3,500 MB/s
- Memory: ~50 GB/s
Size Estimates for Common Data Types
| Data type | Approximate size |
|---|---|
| UUID (stored as bytes) | 16 bytes |
| Timestamp | 8 bytes |
| Integer (32-bit) | 4 bytes |
| Integer (64-bit) | 8 bytes |
| URL (average) | ~100 bytes |
| Tweet / short text | ~300 bytes |
| Image (modern smartphone JPEG) | ~3 MB |
| Image (profile thumbnail, compressed) | ~10-30 KB |
| Video (1 min, 1080p compressed) | ~50 MB |
| MP3 audio (1 min) | ~1 MB |
| Web page HTML (average) | ~50 KB |
Worked Example: Photo Sharing
Given: 100M daily active users, each uploads 2 photos/day on average.
Storage per day:
100M users × 2 photos × 3MB per photo = 600M MB = 600 TB/day
Implication: S3-class object storage. At $0.023/GB/month:
600 TB/day × 30 days = 18 PB/month
18 PB × $0.023/GB = $18,000,000 × 0.023/1000 = $414,000/month in storage alone
Use tiered storage (S3 Standard → Glacier after 90 days) to cut costs.
Writes per second:
100M users × 2 uploads / 86,400 seconds = ~2,300 uploads/sec
Handled by a small fleet of upload processors + S3 direct uploads (valet key pattern reduces server bandwidth).
Reads per second (assuming 10 photo views per user per day):
100M × 10 / 86,400 = ~11,500 reads/sec
Mostly served from CDN at near-$0 per-request bandwidth. Cache hit rate ~90%+ means ~1,150 CDN misses/sec hitting S3.
Database (storing photo metadata):
100M × 2 photos × 300 bytes metadata = 60 GB/day new metadata
Fits in PostgreSQL with partitioning. Not a big data problem at this scale.
Quick Recap
- Memorize the latency tiers: memory ~100ns, SSD ~1ms, same-datacenter network ~500µs, cross-US ~40ms, cross-Atlantic ~80ms. Ratios (not exact numbers) are what matter for design decisions.
- Storage: 2^10 = 1KB, 2^20 = 1MB, 2^30 = 1GB, 2^40 = 1TB. A day has ~86,400 ≈ 10^5 seconds. Round aggressively to powers of 10 — interview estimation is order-of-magnitude reasoning, not accounting.
- A single PostgreSQL primary handles 1-20k writes/sec depending on query complexity and index overhead. A Redis instance handles 100-500k ops/sec. These numbers tell you when you need horizontal scaling.
- For read/write rate estimation: start with DAU × average operations per day, divide by 86,400 to get per-second rate. Add a 2-3× peak multiplier for traffic spikes.
- Let the numbers guide decisions: 600 TB/day upload → object storage choice. 2,300 uploads/sec → manageable with a small fleet. 11,500 reads/sec → CDN is required to avoid serving all from S3 directly.