Back-of-the-Envelope: Estimate Like an Engineer

There's a habit that separates engineers who have opinions about designs from engineers who can decide between them, and it fits on the back of an envelope. Jeff Dean — Google's legendary systems engineer, whose latency numbers you'll memorize next lesson — described it as combining thought experiments with a handful of known numbers to feel out which designs can possibly work. The payoff is blunt: it's better to discover your design is too slow in five minutes on paper than six months into building it.

Here's the surprise that makes this skill learnable: back-of-the-envelope estimation is not about being accurate. It's about being the right order of magnitude — knowing whether you need one server or a hundred, ten gigabytes or ten terabytes, a hundred QPS or a hundred thousand. Within 10× is a win. An answer that's precisely wrong — 2,314.8 QPS computed from numbers you invented — is worth less than one honest digit with stated assumptions.

Physicists have played this game for a century under the name Fermi estimation: decompose a scary unknown into factors you can each roughly guess, guess them, multiply. Engineers play it with requests and bytes. Last lesson gave you the ruler — QPS, percentiles, utilization. This lesson is the method: powers of ten, rounding courage, unit discipline, and the standard ladder from "we have some users" to "we need this much iron." The famous numbers to plug in come next lesson; three full worked walkthroughs after that; then you practice. Today: the technique itself.

The first tool is a notation change that quietly does half the work. Stop thinking in words — thousand, million, billion — and start thinking in exponents: 10³, 10⁶, 10⁹, 10¹² (K, M, G, T). Two reasons this pays immediately.

Multiplication becomes addition. 20 million users × 30 requests each: don't grind it — write 2×10⁷ × 3×10¹, multiply the small numbers in front (2×3 = 6), add the exponents (7+1 = 8): 6×10⁸. Every estimation multiply becomes one tiny product and one addition. Practice until "million times thousand is a billion" (10⁶ × 10³ = 10⁹) requires no thought at all.

And the binary bridge. Computers count in powers of two, but there's a lucky accident: 2¹⁰ = 1,024 ≈ 10³. So 2²⁰ ≈ 10⁶ (a MB is about a million bytes), 2³⁰ ≈ 10⁹ (a GB is about a billion). The ~2% error per hop is nothing at envelope precision, and it lets you slide between "bits and bytes" land and "powers of ten" land without a calculator. (Pedants will note GiB ≠ GB by ~7%. At order-of-magnitude scale, let the pedants have it — ignore the difference.)

Here's the tool with a personality test built in. How many seconds are in a day? 86,400. What should you use? 10⁵. That's a 16% "error," taken on purpose, and making that move without flinching is what this lesson calls rounding courage.

Why is brutal rounding safe? Two reasons, one mathematical and one practical.

The math: errors cancel. An estimate is a product of factors — users × actions × size × seconds. When you round each factor, some round up and some round down, and in the product the errors partially cancel rather than compound. This is Fermi's old secret: keep one significant figure per factor and the final answer typically lands within 2–3× of the careful computation — deep inside order-of-magnitude territory. You are not being sloppy; you are spending precision you never had (your assumptions were guesses to begin with) to buy speed you badly need.

The practice: precision is where estimates go to die. Watch a junior engineer estimate: they'll multiply 86,400 by hand, carry digits, lose the thread, and three minutes later they've produced arithmetic instead of insight. Watch a staff engineer: "call it 10⁵ seconds a day" — and they're already at the answer, attention still on the design. The number of digits you keep is a signal: one digit says I know which part of this number is real.

Two rounding gifts to keep forever: a day ≈ 10⁵ seconds, and — almost too charming to be true — a year ≈ π×10⁷ seconds (31.5 million; the π is pure coincidence, and you'll never forget it now).

Rounding errors shrink in the wash. Unit errors don't — they multiply your answer by 8, or 86,400, and they're the number-one way envelopes go catastrophically wrong. The defense is dimensional analysis, which sounds fancy and is actually just: write every unit down, and cancel them like algebra.

(2×10⁸ requests/day) × (1 day / 10⁵ s) = 2×10³ requests/s

Day cancels day, leaving requests per second — which is what you wanted, so the math is shaped right. That's the rule: if the units don't cancel down to the thing you were solving for, the calculation is wrong no matter how careful the arithmetic was. Units are a proof system you get for free.

The two classic disasters to run the guardrail against:

• Megabits vs megabytes. Networks speak bits (a "100 Mbps" link); storage speaks bytes. Miss the conversion and you're off by 8× — enough to turn "one link is plenty" into an outage. Write Mb and MB as different units and force the ×8 to appear on paper.
• Per-day vs per-second. The silent killer, off by ~10⁵×. "200 million requests" means nothing until the denominator is attached — and everything downstream (QPS, servers, bandwidth) lives per-second. Convert to per-second early, then stay there.

One habit implements all of this: never write a bare number. 2×10⁸ is a mistake waiting to happen; 2×10⁸ requests/day is a calculation in progress.

Now assemble the tools into the standard ladder — the decomposition nearly every capacity estimate walks. One compact pass here; three full-depth walkthroughs (storage, bandwidth, the works) get their own lesson.

The setup: you're designing a photo-sharing app. How much traffic is that?

Step 1 — state assumptions, out loud, and write them down. "I'll assume 10 million daily active users, each making about 20 requests a day, reads outnumbering writes about 100 to 1." These numbers are invented — that's fine. Stated assumptions are correctable; hidden ones are landmines. In an interview, this sentence is the deliverable.

Step 2 — requests per day. 10⁷ users × 2×10¹ requests = 2×10⁸ requests/day.

Step 3 — convert to per-second immediately. 2×10⁸ req/day ÷ 10⁵ s/day = 2×10³ = 2,000 QPS average. (Units: day cancels day ✓.)

Step 4 — peak. Traffic isn't flat — nights are quiet, lunchtime spikes. The standard envelope move: peak ≈ 2–5× average. Take the cautious end: 2,000 × 5 = 10,000 QPS peak. That's the number you size for (remember the knee from last lesson — you don't run boxes at 100%).

Step 5 — split reads and writes. At 100:1, that's ~2,000 read QPS and a rounding-error ~20 write QPS — which quietly tells you something architectural: this is a read-heavy system; the caching chapter is about to earn its keep. (Numbers turning into architecture is the last lesson of this section.)

Step 6 — sanity-check by a second route. Pocket constant: 1M requests/day ≈ 12 QPS. We claimed 2×10⁸/day = 200 × 1M/day ≈ 200 × 12 = 2,400 QPS — same ballpark as our 2,000. Two independent routes agreeing is what "confidence" means on an envelope.

Total elapsed time, done live: about ninety seconds. That's the entire method — assumptions, ladder, per-second early, brutal rounding, peak multiplier, second-route check.

Six conversions cover almost every envelope you'll ever write. These are the arithmetic constants — the latency and hardware numbers join them next lesson.

• 1 day = 86,400 s ≈ 10⁵ s — the workhorse. (Precise-ish variant: 1M/day ≈ 11.6 ≈ 12 QPS; with the 10⁵ rounding, 10 QPS. Either is fine — they're the same answer at this precision.)
• 1M requests/day ≈ 12 QPS — the same fact, pre-packaged for instant conversion in both directions.
• 2¹⁰ ≈ 10³ — the binary bridge; KB→MB→GB→TB is just exponent hops of 3.
• 1 year ≈ π×10⁷ s ≈ 3×10⁷ s — for "how much storage per year" ladders.
• Peak ≈ 2–5× average — pick a number, say it, size for it.
• Reads:writes — often ~100:1 for content systems (10:1 for chattier ones). Always assume and announce rather than ask permission.

And one reflex worth drilling until it's automatic: millions × KB = GB; billions × KB = TB (10⁶ × 10³ bytes = 10⁹). Half of all storage estimates are that one move wearing different clothes.

The arithmetic is the easy half. What actually distinguishes a strong estimator — in a design review or an interview — is where and how they deploy it.

Estimate the crux, not everything. Weak candidates estimate ritually — every quantity, whether it matters or not — and burn ten minutes producing numbers nobody uses. Strong ones ask: what makes THIS problem hard? A URL shortener's crux is read QPS and storage growth; a video platform's is bandwidth and storage; a chat app's is connection count and fan-out. Put the envelope where the risk is; assert the rest.

Narrate, don't mumble. The interviewer can't correct arithmetic they can't hear, and — more importantly — they want to correct your assumptions ("actually, assume 100M users"). Stating assumptions visibly turns estimation from a test into a collaboration.

Land the number somewhere. An estimate that ends with a number is a trivia answer; an estimate that ends with a decision is engineering: "~10K peak QPS — a modest fleet behind a load balancer, nothing exotic; the interesting problem is the storage growth." Numbers exist to pick architectures — that mapping (what 100 QPS vs 100K QPS means for your design) is this section's closing lesson.

Keep two anchors in your pocket for smell-testing: all of Twitter is on the order of ~10⁸ tweets/day (≈ a few thousand tweet-writes per second — surprisingly small!); a single modern server comfortably handles ~10³–10⁴ simple requests/second. If your estimate says a to-do app needs 10⁶ QPS, you didn't discover scale — you slipped a unit. Anchors catch what arithmetic can't.

• "More decimal places, more credibility." Backwards. 2,314.8 QPS from invented inputs signals you don't know which digits are real. One significant figure plus stated assumptions is the senior signature.
• "The design's the same anyway — skip the numbers." 100 QPS and 100K QPS are different worlds — one is a single box, the other is a fleet with sharded state. You can't know which world you're in without the envelope (the full map of those worlds closes this section).
• "86,400 × 2,315 = let me work this out…" Arithmetic-in-circles is the other failure mode. The envelope is a three-minute tool; if you're five minutes into long division, you've lost the thread — round harder.
• "2,000 QPS average → provision 2,000 QPS." Peak is 2–5× average, and last lesson's knee says boxes run at 60–80%, not 100%. Size for peak-at-sane-utilization, or lunchtime takes you down.
• "100 Mbps link = 100 MB/s." ×8. Bits for networks, bytes for storage — write the units and make the 8 show itself.
• "My envelope says X, so X." An envelope unchecked against an anchor is a guess with confidence. Second route or known landmark — then trust it.

• The goal is the right order of magnitude, fast — one server or a hundred, GB or TB. Right-within-10× beats precisely wrong, and five minutes on paper beats six months of building the wrong thing.
• The toolkit: think in powers of ten (multiply mantissas, add exponents; 2¹⁰≈10³ bridges binary), round with courage (1 sig fig per factor — errors cancel in the product; day≈10⁵ s, year≈π×10⁷ s), and let units be the guardrails (write them, cancel them; Mb≠MB ×8, per-day≠per-second ×10⁵ — convert to per-second early).
• The ladder: assumptions (stated aloud) → requests/day → ÷10⁵ → avg QPS → ×2–5 peak → read/write split → sanity-check by a second route (1M/day ≈ 12 QPS) or a known anchor.
• Deploy it like a senior: estimate the crux, narrate assumptions, and end on a decision, not a number.

Next — Numbers to Know: the envelope needs inputs, and some numbers are simply worth memorizing — how fast is a disk, a network hop, a memory read; how much can one server, one database, one link actually do. The 2026 edition of the famous table, and an explorer to make it stick.