Back-of-the-Envelope Estimation — Interview Cheat Sheet

Practice sheet for capacity math in SD interviews. Built after the URL Shortener mock (2026-07-20) where a 10× error appeared twice — once in records/year, once left stale in storage after the input was fixed. This sheet exists to kill that habit.

---

0. The One Discipline That Prevents 90% of Estimation Failures

The interviewer stops trusting every number the moment one doesn't foot. Two rules:

1. Write the exponent explicitly, every time. Not "100M × 365." Write 10⁸ × 365 ≈ 3.65 × 10¹⁰. Powers of ten are where everyone's error rate spikes — slow down there, not on the multiply.
2. When you correct any input, re-run every calc that consumed it before moving on. The classic failure: fix "36.5B → 365B" on the board but leave storage at the old "18 TB." One stale number poisons the whole board.

Say your numbers back as powers of ten out loud: "ten-to-the-eight per day, times three-six-five, is three-six-five times ten-to-the-ten." The verbal check catches the slip the mental math misses.

---

1. Powers of Ten — Memorize Cold

Multiplying/dividing = add/subtract exponents. 10⁸ / 10⁵ = 10³. That's the whole trick for QPS.

---

2. Time — The Numbers That Convert Per-Day to Per-Second

Recipe — X per day → X per second: divide by 10⁵.

• 100M/day = 10⁸ / 10⁵ = 10³ = 1,000/s (precise: 1,157/s — the round-down is fine, say so)

Recipe — X per day → X per year: × 365 ≈ × 3.65 × 10².

• 100M/day × 365 = 10⁸ × 3.65×10² = 3.65 × 10¹⁰ = 36.5 B/year ← the number that got fumbled in the mock. Per YEAR is 36.5B, per 10yr is 365B.

Peak factor: multiply average QPS by 2–3× for peak. State it; don't design to the average.

---

3. Data Sizes

Typical record-field sizes (for estimating row size):

Storage recipe: records × bytes/record. Do records as a power of ten first, then multiply.

• 365 × 10⁹ records × 500 B = 1.8 × 10¹⁴ B = 182 TB

---

4. Base62 Keyspace (URL shortener / ID length)

Pick length so keyspace ≫ total records over retention. 62⁷ (3.5T) vs 365B needed → ~10× headroom → 7 chars. 62⁶ (57B) < 365B → 6 fails.

---

5. Latency Numbers Every Programmer Should Know (rounded)

Interview use: memory is ~1000× faster than SSD, SSD ~100× faster than disk seek, cross-continent RTT ~150 ms. That's why caches exist and why you don't cross an ocean to resolve 7 characters.

---

6. Availability — The Nines

---

7. Powers of Two (when sizing bits / IDs / memory)

---

8. The 5-Step Recipe (do it in this order, every time)

1. Traffic → writes/day → writes/s (÷10⁵) → reads/s (× read:write ratio) → peak (× 2–3).
2. Storage → records over retention (writes/day × 365 × years) → × bytes/record.
3. Bandwidth → QPS × payload size. (Usually trivial — say so and move on.)
4. Cache → hot-set size (Pareto: ~20% of keys). Sanity vs total RAM per node.
5. Special sizing → keyspace / ID length / shard count as the problem demands.

Announce each subtotal. If you correct step 1, re-do steps 2–4.

---

9. Worked Example — URL Shortener @ 100M writes/day (done right)

This is the mock, computed cleanly. Use it as the template.

TRAFFIC
  Writes: 100M/day = 10⁸ / 10⁵ s     = 1,000/s   (precise 1,157; peak ×3 ≈ 3K/s)
  Reads:  100:1     = 10¹⁰/day = 10⁵/s = 100,000/s (peak ×3 ≈ 300K/s)
  → All design pressure is on the READ path. Say this sentence.

RECORDS
  Per year:  10⁸ × 365 = 3.65 × 10¹⁰ = 36.5 B/year
  Per 10yr:  × 10       = 3.65 × 10¹¹ = 365 B          ← the number to get right

CODE LENGTH (base62)
  Need > 365B codes.
  62⁶ = 57B   < 365B  → 6 FAILS
  62⁷ = 3.5T  / 365B ≈ 10× headroom → 7 chars ✅

STORAGE
  365 × 10⁹ records × 500 B = 1.8 × 10¹⁴ B = 182 TB
  (small enough to fit on a handful of nodes → shard for throughput, not capacity)

BANDWIDTH
  Read:  10⁵/s × 500 B = 5 × 10⁷ = 50 MB/s   (trivial)
  Write: 10³/s × 500 B = 5 × 10⁵ = 500 KB/s   (trivial)

CACHE (Pareto 80/20)
  Cache hot code→URL only (~400 B, drop metadata).
  Few hundred M hot entries × 400 B ≈ 150–200 GB Redis, cache-aside + LRU.

Note: the canonical [[Design a URL Shortener]] note uses a 10M/day assumption (→ 9 TB / 5 yr). This worked example uses 100M/day (the mock's number). Both are internally consistent — the point is the method, not the specific scale. Always restate the assumption you picked.

---

10. Self-Drill (redo cold, under 4 min each, exponents written out)

1. Twitter feed: 500M DAU, each posts 2 tweets/day, each tweet read 100×. Tweets/s? Reads/s? Storage/year at 300 B/tweet?
2. Chat app: 50M DAU, 40 messages/user/day, 100 B/message. Messages/s at peak? Storage/year?
3. Video platform: 1M videos uploaded/day, avg 100 MB each. Storage/day? /year? Egress if each watched 1000× at 5 MB streamed?
4. Rate limiter: 1B requests/day across the fleet. Requests/s? If each counter is 16 B and you track per-user for 100M users, memory?
5. URL shortener redo: the Section 9 numbers, from scratch, no peeking. Check every power of ten.

Grading rule (self): any single 10× slip = fail the drill, redo it. That's the whole point.

---

Cross-links

• [[Design a URL Shortener]] — worked capacity section (Section 3) uses this method
• [[Design a Unique ID Generator]] — bit-budget / keyspace math
• [[Design a Distributed Key-Value Store]] — storage + replication sizing
• [[Rate Limiter]] — counter memory sizing