Deep Dive 02 — Back-of-the-Envelope Estimation

Shreyesh kolhe
July 10, 2026

Deep Dive 02 — Back-of-the-Envelope Estimation

Hey everyone! Welcome back to the Deep Dives! 🙏

In Chapter 17 we said "estimate the scale" is Step 2 of every interview. This deep dive teaches you the actual skill — how to size a system in your head in 60 seconds. It's called "back-of-the-envelope" because you scribble rough math on a napkin. You don't need exact answers; you need the right order of magnitude to justify your design choices.

What we will cover:

  • Why rough math beats no math
  • The numbers you must memorize
  • Powers of 2 & 10 for data sizes
  • The QPS calculation trick
  • A full worked example (Twitter)
  • Interview Questions

1. Why Estimate At All?

   The numbers DECIDE the design:

   "10 GB total"        → one machine is fine. No sharding.
   "50 TB total"        → must shard (Ch 08).
   "100 reads/sec"      → one DB is fine.
   "100,000 reads/sec"  → need caching + replicas + more.

   Without a number, you can't justify ANY decision. Estimation
   turns hand-waving into engineering.

2. Numbers You Must Memorize

TIME (for QPS math):
   1 day ≈ 86,400 seconds ≈ ~100,000 (round it!)
   → a handy shortcut: "per day ÷ 100,000 ≈ per second"

DATA SIZES (rough per-item):
   1 character/ASCII        = 1 byte
   A typical short string   ≈ a few dozen bytes
   1 tweet (text)           ≈ 300 bytes (call it ~0.3 KB)
   1 typical web image      ≈ 200 KB – 1 MB
   1 minute of video (HD)   ≈ 50 MB (varies wildly)

POWERS OF 10 (storage ladder):
   KB (10^3) → MB (10^6) → GB (10^9) → TB (10^12) → PB (10^15)

POWERS OF 2 (memory/addresses):
   2^10 ≈ 1 thousand (KB)     2^30 ≈ 1 billion (GB)
   2^20 ≈ 1 million (MB)      2^40 ≈ 1 trillion (TB)

Latency numbers (from Chapter 03, worth re-memorizing)

   RAM read     ~100 ns      SSD read      ~100 µs
   Disk seek    ~10 ms       Datacenter round trip ~0.5 ms
   Cross-world round trip     ~150 ms

3. The QPS Trick (Queries Per Second)

   QPS = (daily actions) / (seconds in a day ≈ 100,000)

   Example: 1 billion actions/day
      → 1,000,000,000 / 100,000 = 10,000 QPS (average)

   ⚠ But traffic isn't flat! Peak is higher than average.
   RULE OF THUMB:  PEAK QPS ≈ 2× to 3× the average.
      → plan for ~20,000–30,000 QPS here.

   Read:write ratio also matters — most systems are read-heavy
   (e.g. 100:1), so reads dominate your capacity planning.

4. A Full Worked Example — "Design Twitter" Sizing

GIVEN (assumptions you state out loud):
   • 300 million monthly users → say 150M daily active
   • Each user posts 2 tweets/day
   • Read:write ratio ≈ 1000:1 (people read WAY more than post)
   • Keep tweets for 5 years

── WRITE QPS ──────────────────────────────────────────────
   Tweets/day = 150M × 2 = 300M tweets/day
   Write QPS  = 300M / 100,000 ≈ 3,000 writes/sec (avg)
   Peak write ≈ 3× → ~9,000 writes/sec

── READ QPS ───────────────────────────────────────────────
   Reads = 1000 × writes → ~3,000,000 reads/sec (avg)
   → MASSIVELY read-heavy → cache + replicas + fan-out (Ch 19)

── STORAGE ────────────────────────────────────────────────
   1 tweet ≈ 300 bytes (text + metadata)
   Per day = 300M × 300 B = 90 GB/day
   Per year = 90 GB × 365 ≈ 33 TB/year
   5 years ≈ 165 TB (text only)
   → way past one machine → SHARDING required (Ch 08)
   (Images/video would add PETABYTES → object storage + CDN)

── BANDWIDTH ──────────────────────────────────────────────
   Write bandwidth = 3,000 tweets/s × 300 B ≈ 0.9 MB/s (tiny)
   Read bandwidth  = 3,000,000/s × 300 B ≈ 900 MB/s (huge!)
   → confirms: reads dominate → CDN & caching essential

CONCLUSION (what the math told us):
   Read-heavy + 165 TB + millions of read QPS →
   caching, read replicas, sharding, and fan-out. The numbers
   JUSTIFIED every architectural choice. ✅

5. The Method in 5 Steps

   1. State assumptions (users, actions/user/day, ratios).
   2. Compute WRITE QPS  = daily writes / 100,000  (×3 for peak).
   3. Compute READ QPS   = write QPS × read:write ratio.
   4. Compute STORAGE    = items/day × size/item × retention.
   5. Compute BANDWIDTH  = QPS × size/item.
   → Then map results to design: big storage → shard; high read
     QPS → cache + replicas; big read bandwidth → CDN.

Pro tip: round aggressively (86,400 → 100,000; 300M → "a few hundred million"). Interviewers want speed and reasoning, not decimal precision.

Interview Questions — Quick Fire!

Q: Why do estimation in a system design interview?

"Because the numbers drive the architecture. Knowing whether it's 10 gigabytes or 100 terabytes tells me whether I need sharding; knowing whether it's 100 or 100,000 queries per second tells me whether I need caching and replicas. Estimation turns vague hand-waving into justified engineering decisions, and interviewers want to see that reasoning."

Q: How do you calculate queries per second from daily usage?

"I divide the number of daily actions by the seconds in a day, which I round to about 100,000 for easy mental math. So a billion actions per day is roughly 10,000 QPS on average. Then I multiply by two or three to estimate peak QPS, since real traffic isn't flat, and I factor in the read-to-write ratio because most systems are far more read-heavy."

Q: How would you estimate storage for a system?

"I multiply the number of items created per day by the average size of each item to get daily storage, then multiply by the retention period. For example, 300 million tweets a day at about 300 bytes each is roughly 90 gigabytes a day, which over five years is well over a hundred terabytes — telling me immediately that sharding is required. Media would add orders of magnitude more, pushing toward object storage and CDNs."

Q: Why round so aggressively?

"Because the goal is the right order of magnitude, not precision. Rounding seconds-per-day to 100,000 or users to a few hundred million keeps the math fast and doesn't change the conclusion — whether I need one machine or a thousand. Interviewers care about the reasoning and the ballpark, not exact decimals."

Key Points to Remember

ConceptKey Takeaway
PurposeNumbers justify design: storage size → sharding; read QPS → cache/replicas.
QPS trickdaily / 100,000 ≈ per second. Peak ≈ 2–3× average.
Storageitems/day × size/item × retention.
Read-heavyApply the read:write ratio — reads usually dominate capacity.
Round hardOrder of magnitude beats precision. Speed + reasoning win.

What's Next?

Deep Dive 03 opens the engine that powers modern event-driven systems: how Kafka works inside. Topics, partitions, offsets, and why it can handle millions of messages per second.

Keep designing, keep scaling! See you in the next one!