Estimation Walkthroughs: QPS, Storage, Bandwidth

You have the method (Back-of-the-Envelope) and the numbers (Numbers to Know). This lesson is the missing third piece: watching the whole thing run, three times, start to finish — the way a colleague would do it at a whiteboard, narrating every assumption and rounding decision out loud.

The three walkthroughs are chosen deliberately, one per dimension: a URL shortener, where the story is pure traffic (QPS); a photo-sharing app, where the story is storage that accumulates forever; and a video-streaming service, where the story is bandwidth that dwarfs everything else you've ever estimated. Same ladder each time — assumptions, per-day, per-second, peak, the dimension's own multipliers, a sanity anchor, and a decision at the end — but a different dimension dominates each product, and noticing which one is the real skill this lesson installs.

Read these actively: cover the next line and guess it before you look. Everything uses the pocket constants (a day ≈ 10⁵ s, peak ≈ 2–5×, reads:writes ≈ 100:1) and the number sheet (Postgres ~5–10K QPS, 10 Gbps = 1.25 GB/s). Your own turn — with checked answers — is the next lesson.

The ask: "We're building a URL shortener. What kind of traffic and storage are we designing for?"

Assumptions, out loud: "I'll assume 100 million new URLs a month, a 100:1 read-to-write ratio (links are written once, clicked forever), records around 500 bytes (short code, long URL, timestamps, owner), kept for 5 years."

Writes. 100M/month ≈ 3.3M/day. Divide by 10⁵ seconds: ~33 → call it 40 writes/second. Even ×3 for peak, ~120 writes/s — a rounding error for any database on the number sheet. Writes are not the story.

Reads. 100 × the writes: 40 × 100 = 4,000 QPS average. Peak ×5: 20,000 read QPS. There's the story.

Storage — and the twist. 100M/month × 60 months = 6×10⁹ records × 500 B = 3×10¹² B = 3 TB. Five years of everything, and it fits on one NVMe drive (double it for indexes — still one drive). Say that in the interview; it's the moment the estimate starts driving the design.

Sanity anchors. Postgres does 5–10K simple QPS — 20K peak reads is 2–4× one box. And reads of hot links are wildly skewed (the 80/20 from Why Caching Wins): caching the hottest ~100M mappings costs 100M × 500 B = 50 GB — one Redis box absorbs nearly all of it.

⟶ The decision. Storage is trivia, writes are trivia; this system is a read path. One database with a cache in front (cache-aside, long TTLs — links never change) and the real puzzle isn't capacity at all: it's the keyspace (7 Base62 characters ≈ 3.5×10¹² codes) and the read-path hit rate. Ninety seconds of arithmetic just told you where the design effort goes.

The ask: our photo app from the envelope lesson — the one we already sized at 2,000 QPS average, 10K peak — needs a storage plan. Notice the continuity: QPS answered, but nothing yet about bytes.

Assumptions, out loud: "10M DAU; say 10% upload one photo a day → 1M photos/day; call a photo 500 KB all-in after server-side compression, including thumbnails."

The daily slice. 10⁶ photos × 5×10⁵ B = 5×10¹¹ B = 500 GB/day.

The year — where storage differs from everything else. Traffic resets every second; storage accumulates. 500 GB × 365 ≈ 182 TB → round with courage: ~200 TB/year. And nobody stores bytes once: ×3 replication → 600 TB/year raw. Five years ≈ 3 PB. (Forgetting the ×3 is the single most common storage-estimate bug — it's a 3× error sitting in one forgotten line.)

Metadata check. 1M rows/day × 1 KB = 1 GB/day — replicated and yearly, ~1 TB against the blobs' 600: a thousandth. The database never touches image bytes; it holds pointers.

The wire-versus-disk surprise. That 500 GB/day of uploads, as bandwidth: 5×10¹¹ B ÷ 10⁵ s = 5 MB/s ≈ 40 Mbps average ingest. Trivial! A petabyte-scale storage problem rides in on a home-internet-sized pipe — because storage integrates over time; the wire only carries today's slice. Hold that thought; the next walkthrough inverts it.

Sanity anchor. Instagram runs ~100M photos/day — our app is 1% of Instagram. Plausible for 10M DAU ✓.

⟶ The decision. Blobs go to object storage (S3-style) with a CDN in front (Caching at the Edge); the database holds metadata only; and since most photos are viewed for a week and stored for a decade, lifecycle tiering (hot → cold after ~90 days) is where real money is saved. The estimate didn't just size the system — it split it in two.

The ask: "How much bandwidth does a video-streaming service need?" This is the dimension that breaks people's intuition, so watch the exponents.

Assumptions, out loud: "Say 1 million concurrent viewers at prime time. Streams adapt (SD/HD/4K), so I'll use an effective average of 5 Mbps — 1080p's bitrate, from the number sheet (4K runs 15–25)."

Egress — the whole story in one multiply. 10⁶ viewers × 5×10⁶ bits/s = 5×10¹² bits/s = 5 Tbps. Watch the units: bits. In bytes: ÷8 = 625 GB/s, sustained.

Make it physical. A 10 Gbps port moves 1.25 GB/s, so 5 Tbps = 500 fully saturated 10-gigabit ports — no origin rack on Earth serves this. The estimate has already made the architecture decision: this traffic must be served from the edge (CDNs: Caching at the Edge — recall Netflix pushes ~95% of its bits from boxes inside ISPs). We didn't choose a CDN; the arithmetic did.

Ingest, for contrast. Uploads at YouTube scale run ~500 hours of video per minute; at ~5 GB/hour that's 2.5 TB/min ≈ 40 GB/s ≈ 330 Gbps — a colossal number that is still ~15× smaller than egress. Video is a broadcast business: one byte in, thousands out. (And each upload gets transcoded into an ABR ladder of renditions — multiply stored bytes ×2–3 and reuse Walkthrough 2's logic for the library.)

⟶ The decision. Egress is the cost center — the single line item that dominates the P&L. CDN non-negotiable; and the bitrate ladder becomes a million-dollar knob: shaving the effective average from 5 to 4 Mbps deletes a full terabit per second of egress. When an estimate ends by pointing at the company's biggest bill, it has done its job.

Line the walkthroughs up and the machinery is identical — assumptions → per-day → per-second → peak → anchor → decision. What changed is which multiplier mattered:

• QPS is a rate. It exists now and resets every second. Ladder: users → actions → ÷10⁵ → ×peak.
• Bandwidth is rate × size. Also now, also resets — just heavier per event (and denominated in bits, the eternal ×8 trap).
• Storage is rate × size × time × replication. The only dimension that accumulates — every day's slice lands on top of every previous day's, forever, times three. That's why the photo app's trivial 40 Mbps of ingest quietly becomes 3 PB.

And the meta-skill — the crux idea from the envelope lesson, now with evidence: the product type tells you which dimension dominates before you calculate anything. Text and links → traffic. A media library → storage. Live or streaming → bandwidth. Aim the envelope at the dominant dimension first; assert the others in a sentence each. Every strong walkthrough you'll ever give follows that shape — and every one ends on a decision, because a number that lands nowhere is trivia.

Interviewers and design reviewers grade these three calculations constantly. The recurring deductions, in descending order of frequency:

• Forgot peak. Sized for the 4,000-QPS average, melted at the 20K lunchtime spike — then remembered the utilization knee too late. Average is for understanding; peak is for sizing.
• Forgot replication. Every storage answer that doesn't say "×3" is off by 3× before compression or renditions even enter the room. Cheapest correction in the business: one spoken line.
• Bits versus bytes on the bandwidth math. The video answer changes by 8× on this one habit. Write Mb and MB as different units and cancel them (the guardrail from the envelope lesson).
• No decision at the end. "5 Tbps" is trivia; "5 Tbps, therefore CDN, therefore the bitrate ladder is the cost knob" is engineering.
• False precision and circling. 2,314.8 QPS from invented inputs, or five minutes of long division — both signal the same thing: the method isn't loaded yet. One digit, stated assumptions, ninety seconds.
• Estimating everything equally. Ten minutes spent sizing the shortener's storage (3 TB — who cares) is ten minutes not spent on its read path. Dominant dimension first.

• The shortener taught QPS: writes were noise (~40/s), reads were the system (20K peak) — and the estimate redirected the design to the cache and the keyspace. Storage: 3 TB in 5 years. One drive.
• The photo app taught storage: the only dimension that accumulates — 500 GB/day × 365 × 3 replication ≈ 600 TB/year, while metadata stayed a thousandth and ingest averaged a laughable 40 Mbps. Blobs to object storage + CDN; the database holds pointers.
• The video service taught bandwidth: 1M viewers × 5 Mbps = 5 Tbps = 500 saturated 10-gig ports — the arithmetic chose the CDN, and the bitrate ladder became the company's biggest cost knob.
• One ladder, three dimensions — rate · rate×size · rate×size×time×replication — and the product type tells you which dominates before you touch a number. End every estimate on a decision.

Now it's your turn. Next — Estimation Practice: three fresh problems, your envelope, and checked answer ranges that tell you immediately whether your instincts have loaded. No peeking at the ladder — that's the point.