System Design · Core

Back-of-Envelope Estimation

Quick math for RPS, storage, and bandwidth so design choices are grounded.

In simple words: Turn product assumptions into requests per second, storage, and bandwidth. These numbers tell you which scaling tools are actually needed.

Concrete example: If Netflix serves 100,000 simultaneous viewers at 5 Mbps each, the outgoing traffic is about 500 Gbps. That immediately justifies a CDN instead of serving every stream from one origin.

1. Why estimate

Numbers decide whether you need a cache, shards, or a CDN — not vibes. Interviewers want to hear you say assumptions out loud before you draw boxes.

2. Typical questions

QPS / RPS (peak and average)
Storage over N years
Bandwidth (ingress/egress)
Cache size / hit-rate assumptions

3. Powers of ten (memorize)

1 day = 86,400 seconds (~100k; use 10^5 in interviews) 1 month ≈ 2.5M seconds (~2.5 × 10^6) 1 year ≈ 30M seconds 1 KB = 10^3 bytes, 1 MB = 10^6, 1 GB = 10^9, 1 TB = 10^12

Round aggressively to powers of 10. Being within 2× is fine — the goal is to show reasoning, not perfect arithmetic.

4. Worked example — URL shortener

Assumptions: 100M new URLs / month Write QPS ≈ 100e6 / (30*24*3600) ≈ 40 writes/s Peak ≈ 2–5× average → ~200 writes/s Reads 100× writes → ~20k reads/s Storage: 100M × 500 bytes ≈ 50 GB / month 5 years ≈ 3 TB (+ indexes/replicas)

Takeaway: modest writes, heavy reads → cache + read replicas; one primary DB may still work for writes.

5. Worked example — Instagram-style feed writes

Assumptions: 500M daily active users Each user posts 0.5 times/day on average Posts per day ≈ 250M Write QPS (average): 250M / 86,400 ≈ 2,900 posts/s Peak ≈ 3× → ~9,000 posts/s Storage per post (metadata + small text): ~2 KB Daily storage ≈ 250M × 2 KB ≈ 500 GB/day 1 year ≈ ~180 TB raw (before replicas)

Say out loud: "I'll assume X users, Y actions each, convert to per-second, multiply by peak factor 2–3×."

6. Cache sizing (quick)

20k read QPS, 80% cache hit rate → 4k requests/s hit DB If each DB read takes ~5 ms of service time, verify the DB can sustain 4k reads/s Cache stores hot 20% of keys serving 80% traffic (Pareto) If 100M keys total, cache ~20M keys × 1 KB ≈ 20 GB RAM

7. Bandwidth example — photo upload app

Assumptions: 10M daily active users Each uploads 2 photos/day, avg 2 MB per photo Upload volume per day: 10M × 2 × 2 MB ≈ 40 TB/day ingress Average upload bandwidth: 40 TB / 86,400 s ≈ 460 MB/s (~3.7 Gbps sustained average) Peak can be 3–5× → plan for ~15 Gbps at peak Takeaway: heavy media needs object storage + CDN; API servers should not proxy full files.

8. Latency reference (memorize order of magnitude)

Operation	~Latency
L1 / L2 cache	1–4 ns
RAM	~100 ns
SSD read	~100 µs
Same-DC RTT	~0.5 ms
HDD seek	~10 ms
Cross-country RTT	~150 ms

9. Throughput ballparks

SSD sequential read ~500 MB/s; 1 Gbps NIC ~125 MB/s
One modest web box: often ~1k–10k simple req/s depending on work
One DB primary: often ~1k–5k simple writes/s before you shard

Rule of thumb in interview: say assumptions out loud round aggressively (powers of 10) show peak = k × average

Quick revision

Always state assumptions before multiplying.
Derive: writes/s, reads/s, GB/month, peak multiplier.
Latency ladder: RAM << SSD << disk << WAN.
Use numbers to justify cache / shard / CDN.