Back-of-Envelope Estimation

Why It Matters

Capacity math is step 2 of every HLD ([[SD Interview Framework & Pitfalls]]). Point isn't a precise number — it's justifying architecture. "Writes fit on one Postgres box" vs "writes need sharding + a queue" is decided by one QPS calc. Skip the math → every later decision is a guess. Interviewer watches whether the numbers drive the design, not the arithmetic.

Round hard. 86,400 s/day ≈ 100,000. 1 million ≈ 2^20. Goal is right order of magnitude, fast.

Numbers to Memorize

Powers of 2 → data size

Time → seconds (the QPS denominators)

1 day   = 86,400 s    ≈ 10^5 s   (round to 100k)
1 month ≈ 2.5 million s ≈ 2.5×10^6 s
1 year  ≈ 31.5 million s ≈ 3×10^7 s

Latency ladder (Jeff Dean, orders of magnitude — memorize the ratios, not digits)

Takeaways that win points: memory is ~100k× faster than disk seek → cache hot data. Cross-continent RTT (150 ms) dwarfs everything → don't chat across regions, co-locate. SSD ~100× faster random read than HDD → why nobody spins disks for OLTP.

The Estimation Recipe

Always the same 5 quantities, in order:

1. DAU → QPS. QPS_avg = (DAU × actions/user/day) / 86,400. Then QPS_peak ≈ 2–3 × QPS_avg.
2. Read:write ratio. State it explicitly (e.g. 100:1 for a feed, 1:1 for a chat). Drives whether you optimize reads (cache/replicas) or writes (queue/shard).
3. Storage = objects/day × size/object × retention. Multiply out to 5 years for the "do we shard" answer.
4. Bandwidth = QPS × payload size. Split ingress vs egress; egress is what CDN offloads.
5. Memory for cache. Apply the 80/20 rule — cache the hot 20% of daily reads. cache_size = 0.2 × daily_read_volume × object_size.

Worked Example — Twitter-scale Feed

Given: 300M DAU, each user posts 2 tweets/day, reads timeline 50×/day, tweet = 300 bytes text + metadata ≈ 1 KB, 5-year retention.

# 1. QPS
writes/day = 300M × 2        = 600M
reads/day  = 300M × 50       = 15B
write QPS_avg = 600M / 86,400 ≈ 7,000
read  QPS_avg = 15B  / 86,400 ≈ 170,000
peak read QPS ≈ 3 × 170k      ≈ 500,000

# 2. Ratio
read:write ≈ 25:1  → read-heavy → fan-out + cache, replicas for reads

# 3. Storage
writes/day × size = 600M × 1 KB = 600 GB/day
5-year = 600 GB × 365 × 5       ≈ 1.1 PB   → must shard, cold storage tiering

# 4. Bandwidth
read egress = 170k QPS × 1 KB   ≈ 170 MB/s  ≈ 1.4 Gbps steady → CDN/edge cache

# 5. Cache (hot 20% of reads)
0.2 × 15B reads × 1 KB          = 3 TB hot set → distributed Redis cluster, not one box

Design conclusions the numbers forced: read-heavy 25:1 → precompute timelines (fan-out on write) + heavy caching; 1.1 PB → shard by user_id, tier old tweets to blob storage; 3 TB hot set → Redis cluster, sharded, not a single instance. Every one of these is defensible because a number pointed at it.

Sanity-Check Anchors

Ballpark ceilings to catch nonsense answers:

If your calc says "1 Postgres node does 500k writes/s," you rounded wrong or need sharding. These anchors are how you know.

Interview Drill

Q: You estimate 500k peak read QPS. Walk me from that number to a concrete component decision. A: 500k QPS × 1 KB ≈ 500 MB/s egress — one NIC (10 Gbps ≈ 1.25 GB/s) survives but leaves no headroom, and one DB node (~10k reads/s) is 50× short. So: read replicas won't be enough alone (need ~50 of them) → put a cache in front sized to the hot set, serve the 80% hit rate from Redis, and only the ~100k QPS miss traffic touches replicas. The QPS number directly sized both the cache tier and the replica count.

Q: When do you skip the estimation? A: Never skip it, but keep it to 2 minutes. Even a rough calc that says "this fits on one box" is a result — it tells you not to over-engineer with sharding/queues. The mistake is silent hand-waving, not spending too long.

Cross-links

[[SD Interview Framework & Pitfalls]] · [[Core Vocabulary & Quality Pillars]] · [[Latency vs Throughput]] · [[Caching & Redis]] · [[Database Replication & Sharding]] · [[News Feed - Twitter Feed]]