Back-of-Envelope Math

Why Engineers Estimate

Back-of-envelope math isn't about precision: it's about catching factor-of-100 errors in thirty seconds. "Will one machine handle this?" "Is that design's worst case 600 requests in flight, or 60,000?" "Does this table fit in memory?" The answers steer designs, and being roughly right immediately beats being precisely right next sprint.

The five questions all need numbers to bite: this lesson is the numbers. It's also, frankly, an interview event: "how much storage would that need?" is asked out loud, and the expected performance is confident rounding, narrated as you go. Which brings us to the one rule that governs everything below:

Round shamelessly. A day is 86,400 seconds: call it 100,000. A month is ~2.5 million: call it 3. You're hunting powers of ten, not decimals, and clean numbers keep your head clear at the whiteboard. (Round in the safe direction when it matters: overestimate load, underestimate capacity.)

The Ladder: Numbers You Memorize

Every latency estimate in this course walks one ladder. Learn it as rungs, each roughly 10-100× the one above:

Three course-shaping facts live in this ladder. A cache hit (~1 ms) versus a database query (~10-15 ms) is the whole business case of Module 4. Sequential disk writes versus scattered ones (the WAL lesson's foundation) is a rung-sized gap. And anything cross-region costs ~100 ms per round trip, which is why chatty designs die the moment they go multi-region.

For sizes, you need even less: a character is a byte, an ID is ~16-36 bytes, a typical database row is ~1 KB, an image is ~100 KB-1 MB, and the units step by thousands: KB, MB, GB, TB. A million 1 KB rows is a gigabyte. A billion is a terabyte. That's most of what you'll ever need.

Calculation 1: Rate × Duration = How Many at Once

How many things are in progress at the same time? Multiply how fast they arrive by how long each one takes.

things in flight = rate × duration

• 300 requests per second, each taking 2 seconds to complete: 300 × 2 = 600 requests in progress, each holding a thread or connection. If your pool has 200... now you know, thirty seconds into the design, not during the outage.
• The same formula runs backward for queues: a backlog of 552,000 messages, drained at 400 per second: 552,000 ÷ 400 ≈ 1,400 seconds ≈ 23 minutes to catch up.

This is the course's single most-used calculation (it has a formal name, Little's law, worth knowing for interviews). It sizes thread pools, connection pools, bulkhead compartments, queue drain times, and, run against a hung dependency's timeout, predicts exactly when a service locks up: rate × how-long-you-wait = threads consumed.

Calculation 2: Availability Multiplies (Downward)

A request that needs all of several parts to succeed multiplies their availabilities: and multiplication only goes down.

chain availability = each part's availability, multiplied together

Five sequential dependencies at 99.9% each: 0.999⁵ ≈ 99.5%. The junior-friendly shortcut for small failure rates: just add the failure rates. Five parts × 0.1% ≈ 0.5% failure: same answer, no exponents at the whiteboard.

Then translate percentages into human time, because "99.9%" hides its meaning:

Two design lessons fall straight out of the math. Every "nine" costs roughly 10× the effort of the last one. And since chains only multiply downward, the escape isn't making every link perfect: it's shortening the chain and removing links from the must-succeed list: which is the entire argument of the graceful degradation lesson, previewed here as arithmetic.

Calculation 3: Hit Ratios (and Why 90% Isn't Close to 99%)

For any cache, two numbers follow from the hit ratio h:

average latency = h × (fast) + (1−h) × (fast + slow) load reaching the database = (1−h) × request rate

Run it: 12,000 requests per second, cache hit 1 ms, database trip 15 ms.

• At 99%: average ≈ 1.15 ms, and the database sees 1% × 12,000 = 120 queries/second.
• At 90%: average ≈ 2.5 ms (fine!), but the database sees 1,200 queries/second: ten times more.

There's the trap worth saying aloud in interviews: the difference between 99% and 90% is not nine percent: it's 10× the database load, because what matters is the miss rate, and it went from 1% to 10%. Caches are judged by their misses. (This is also why the stampede lesson's herd is so violent: a hot key expiring briefly drives h toward zero for that key, and the formula does the rest.)

Calculation 4: Sizing: From "Per Day" to "Per Second" to Terabytes

Requirements arrive in days; systems are sized in seconds. The conversion is one clean division:

per second ≈ per day ÷ 100,000

• 10 million orders per day ≈ 100 per second, average. Then apply the peak rule: real traffic isn't flat, so peak runs 3-5× average (more for spiky products): call it 300-500 per second to size for.

Storage is multiplication with the size numbers from the ladder:

• 10 million orders/day × 1 KB per order × 365 days ≈ 3.7 TB per year: one healthy machine's worth, not a sharding emergency. Knowing that in ten seconds prevents a lot of over-engineering.

The Demo: Sixty Seconds on the URL Shortener

The last lesson sketched the design; now size it, out loud:

• "Say 100 million redirects a day: divide by 100k: 1,000 per second average, size for ~4,000 peak."
• "Each mapping is two URLs and change: call it 1 KB. 500 million total links: 500 GB. Fits on one database with room: shard eventually, not today."
• "Reads are ~100:1 over writes, and popularity is skewed: cache the hot 1%: 5 million rows: 5 GB of cache memory: trivial. At 99% hit ratio the database sees 10 redirect-misses per second: a rounding error."
• "In flight: 4,000 per second × ~2 ms each = 8 concurrent requests. This service is small. One good box plus a replica, a cache, and honest failure handling."

Sixty seconds, five numbers, and the design conversation is now anchored: no component was invented for load that doesn't exist, which is its own kind of senior judgment.

Using It in Interviews

• Narrate assumptions before arithmetic: "assuming 1 KB per record and 10 million a day..." Interviewers correct assumptions happily; they only grade silence harshly.
• Round before multiplying, and sanity-check the units at the end (per-second × seconds = a count; bytes × count = storage: if the units don't cancel, the answer's wrong).
• Let the numbers veto the design. The most impressive sentence in many interviews is "at this scale we don't need that yet": arithmetic as restraint, the first lesson's price-tag thinking with digits attached.

TL;DR Card