Back-of-the-Envelope Estimation

Turn DAU and payload sizes into QPS, storage and server counts using numbers you can do in your head.

FresherTheory14 min read

Read these first

Functional vs Non-Functional Requirements

Why estimation matters in interviews

Estimation proves you can connect product metrics to infrastructure. It tells the interviewer whether you need one app server or a hundred, and whether a single database survives the workload.

What to estimate

Traffic — requests per second (reads and writes separately).
Storage — total bytes now and in five years.
Bandwidth — egress from servers and CDN.
Memory — cache size if you plan to cache hot data.
Compute — rough server count from QPS per core.

Round aggressively. The goal is the right order of magnitude, not precision to three decimal places.

Estimation → architecture sizing

QPS and storage estimates drive EKS pod count, RDS size, and Redis memory.

Useful constants

Memorise these shortcuts — they save minutes in a live session.

Fact	Approximation
1 day	86,400 seconds ≈ 100K seconds
1 year	≈ 400 days (for quick math) ≈ 3 × 10⁷ seconds
1 million	10⁶
1 billion	10⁹
1 KB	10³ bytes; 1 MB ≈ 10⁶ bytes; 1 GB ≈ 10⁹ bytes
1 Gbps	≈ 125 MB/s

1 day
Approximation86,400 seconds ≈ 100K seconds
1 year
Approximation≈ 400 days (for quick math) ≈ 3 × 10⁷ seconds
1 million
Approximation10⁶
1 billion
Approximation10⁹
1 KB
Approximation10³ bytes; 1 MB ≈ 10⁶ bytes; 1 GB ≈ 10⁹ bytes
1 Gbps
Approximation≈ 125 MB/s

Example: photo-sharing app

Given: 50 million DAU, each user uploads 2 photos/day (500 KB each) and views 100 photos/day (200 KB each).

Write QPS:

Java

Uploads:  50M × 2 / 100K ≈ 1,000 writes/sec (peak × 3 ≈ 3K)
Views:    50M × 100 / 100K ≈ 50,000 reads/sec (peak × 3 ≈ 150K)

Storage (5 years):

Java

Daily new photos: 50M × 2 = 100M photos
Daily bytes:      100M × 500 KB ≈ 50 TB/day
5-year raw:       50 TB × 365 × 5 ≈ 90 PB (before replication)

Say aloud: "Reads dominate at roughly 150K QPS peak; storage is petabyte-scale, so object storage with lifecycle tiers, not a single relational database."

Example: URL shortener

Given: 500 million new URLs/month, 10:1 redirect-to-create ratio, 500 bytes metadata per URL.

Java

Creates:    500M / (30 × 100K) ≈ 200 creates/sec
Redirects:  200 × 10 ≈ 2,000 reads/sec (modest — cache-friendly)

5-year URLs: 500M × 12 × 5 = 30 billion rows
Metadata:    30B × 500 B ≈ 15 TB (fits sharded SQL or wide-column store)

Bandwidth and cache sizing

Bandwidth (photo views):

Java

150K req/s × 200 KB ≈ 30 GB/s egress
→ CDN is mandatory; origin cannot serve this directly

Cache (hot data):

Java

20% of photos get 80% of views (Pareto)
Hot set ≈ 0.2 × daily_views × 200 KB ≈ few TB
→ Redis cluster or CDN edge cache, not one machine

Server count (rough)

Assume one modern app core handles ~1K simple API requests/sec with headroom:

Java

150K read QPS / 1K per core ≈ 150 cores → ~20 eight-core instances
(+ load balancer, autoscaling, geographic distribution)

This is a starting point for discussion, not an purchase order.

Estimation worksheet

Use this template in any interview:

Java

assumptions:
  dau: 10_000_000
  actions_per_user_per_day: { read: 50, write: 2 }
  payload_bytes: { read: 2_000, write: 1_000 }
  retention_years: 5

derived:
  avg_read_qps:  dau * read / 100_000
  peak_multiplier: 3
  daily_storage: dau * write * write_bytes

Aspect	Good estimate	Weak estimate
Units	States QPS, bytes, years explicitly	Says 'a lot of traffic'
Rounding	Powers of ten, one significant figure	Exact to 4 decimals
Conclusion	Links number to design choice	Stops at the number
Peaks	Mentions 2–3× average for peaks	Uses daily average as QPS

Units
Good estimateStates QPS, bytes, years explicitly
Weak estimateSays 'a lot of traffic'
Rounding
Good estimatePowers of ten, one significant figure
Weak estimateExact to 4 decimals
Conclusion
Good estimateLinks number to design choice
Weak estimateStops at the number
Peaks
Good estimateMentions 2–3× average for peaks
Weak estimateUses daily average as QPS

Quick recall

Everything you need if you only revisit this box.

Estimate QPS, storage, bandwidth, and cache size — link each to a design decision.
Use 100K seconds per day and round to powers of ten.
Separate read and write QPS; peaks are typically 2–3× average.
Storage = daily volume × retention; account for replication separately.
Bandwidth = QPS × payload size — large media forces CDN.
Wrong by 2× is fine; wrong order of magnitude means wrong architecture.

Test yourself

Answer these before moving on — recall is what makes it stick.