Back-of-the-Envelope Estimation

A fast method for QPS, storage, bandwidth and memory estimates — and turning them into decisions.

Back-of-the-envelope estimation turns vague scale ("lots of users") into numbers that drive decisions: do we need to shard? Will this fit in memory? Is one Kafka cluster enough? Interviewers don't expect precision. They expect a fast, structured calculation and — most importantly — a conclusion that changes your design. For the reference numbers, see Numbers to Know.

When to estimate

Not at the start by reflex. Many interviewers prefer you only estimate when a number will influence a decision.
Do estimate when choosing between designs: single database vs sharded, cache everything vs cache hot items, one region vs many, push vs pull fan-out.
Say it out loud: "Let me check whether this fits on one machine."

The method

State assumptions — daily active users, actions per user, object sizes. Round aggressively.
Compute throughput — requests per second, average and peak.
Compute storage — per day, per year, with replication.
Compute bandwidth or memory if relevant.
Conclude — what does this mean for the design?

Shortcuts that make the math easy

Use powers of ten and round at every step: 7 × 3 is "about 20."

Worked example: a photo-sharing app

Assumptions: 100M daily active users; each views 50 photos and uploads 0.1 photos a day; a photo is ~2 MB (originals) and its metadata ~1 KB.

Uploads: 100M × 0.1 = 10M/day  ≈ 10M / 100K s = 100 uploads/s   (peak ~300/s)
Views:   100M × 50  = 5B/day   ≈ 5B / 100K s  = 50K views/s     (peak ~150K/s)

Photos:   10M/day × 2 MB = 20 TB/day → ~8 PB/year → blob storage (S3), not a database
Metadata: 10M/day × 1 KB = 10 GB/day → ~4 TB/year → fits one sharded or even single DB cluster for a while

Views: 150K/s × ~200 KB (resized image) ≈ 30 GB/s at peak → must be served from a CDN

Conclusions: blobs go to S3 behind a CDN; metadata fits a modest database cluster; the read path is 500× the write path, so cache aggressively and precompute resized images.

Will it fit in memory?

A common deep-dive question:

Hot metadata: 20% of the last 30 days of photos = 0.2 × 300M × 1 KB ≈ 60 GB
→ fits in a small Redis cluster (a few nodes with 32–64 GB each)

How many machines?

A typical app server handles 1K–10K simple requests/s; a single PostgreSQL instance roughly 10K–50K simple queries/s; Redis 100K+ ops/s per node; a Kafka broker hundreds of MB/s.
150K views/s ÷ ~5K per server ≈ 30 app servers, plus headroom for failures → ~50.

[!WARNING] Don't stop at the number "That's 50,000 QPS" earns nothing on its own. "That's 50,000 reads per second, which is more than one database should take, so we'll put a cache in front of it with a high hit rate" earns full credit.

[!INTERVIEW] Estimating out loud "Ten million uploads a day is about a hundred per second — trivial for writes. But at 2 MB each that's 20 terabytes a day, so images must go to object storage. Reads are 500 times higher at about 50K per second, so the real design problem is the read path: CDN for images and a Redis cache for metadata."