Estimation Practice

Your Turn

Two lessons of method, one lesson of numbers, three worked walkthroughs — the loading phase is over. This lesson is a gym: three fresh problems, your envelope, and a checker that grades every rung of your ladder.

Three rules make the practice actually work:

Paper first. Work each problem with a pen before touching an input box — the struggle to produce the number is the learning; the checker is only there to referee. (Cover-and-guess got you here; now it's produce-and-check.)
The givens are fixed on purpose. In real life you choose the assumptions — that's next section's discussion. Here the assumptions are handed to you so that your answers are checkable against honest ranges: within 2× passes, because rounding style (10⁵ vs 86,400) legitimately wiggles results and order-of-magnitude is the game.
Read your misses. When a rung comes back wrong, the checker doesn't just say wrong — it reads the ratio of your answer to the right one and names the mistake: off by ~10⁵ means you never converted to per-second; off by 8, bits versus bytes; off by 3, the forgotten replication. Every miss is one of this section's lessons wearing a number — which makes wrong answers the most valuable thing in this lesson.

Pocket constants within reach, calculator away. Ninety seconds a problem is the bar you're training toward.

A practice-arena infographic for back-of-the-envelope estimation, showing three problem cards with their ladders left deliberately blank. Card one, QPS, the chat app: fifty million daily users, forty messages sent per user per day, with three blank steps - messages per day, average per second, and times five peak - each shown as an empty answer box with question marks. Card two, storage, the podcast platform: two thousand hours uploaded per day, one hour is about sixty megabytes, replicate times three, with blank steps for gigabytes per day, terabytes per year, and replicated terabytes per year. Card three, bandwidth, the live sports stream: two hundred thousand concurrent viewers at seven-twenty-p around three megabits per second, with blank steps for total gigabits per second, gigabytes per second, and ten-gigabit ports. Beneath the cards runs the miss decoder, a strip translating error ratios into diagnoses: off by about ten to the fifth means per-day versus per-second, off by a thousand is a K M G slip, off by three hundred sixty-five is day versus year, off by eight is bits versus bytes, off by five is the forgotten peak, off by three is the forgotten replication. A footer reads: do it on paper first - the checker grades each rung and tells you which constant you dropped. The palette is dark slate with sky, amber, and red problem cards and a violet decoder strip.

The Arena: Three Problems

One problem per dimension, none of them seen before: a chat app (traffic — where does 50M users' chatter land per second?), a podcast platform (storage — with a twist you'll enjoy discovering), and a live-sports stream (bandwidth — smaller than the video giant from the walkthroughs, but the same physics). Type each rung; check the ladder; read your misses.

The practice arena. Three fresh estimation problems - a chat app's send QPS, a podcast platform's yearly storage, a live-sports stream's egress - each broken into the ladder's rungs with free-typed numeric answers checked against honest ranges (within 2x passes; the givens are fixed so the math is checkable). The part that teaches: when a rung is wrong, the miss decoder reads your error ratio and names the mistake - off by about a hundred thousand means you never left per-day, off by eight is bits versus bytes, off by three is the forgotten replication, off by five is the forgotten peak. Work on paper first; every miss is one of the section's lessons wearing a number.

Reading Your Misses

The decoder's table is worth internalizing beyond this page, because these exact ratios are how estimation errors present in the wild — in your own design docs and in other people's:

you're off by…	you probably…
~100,000×	never converted per-day → per-second (the ÷10⁵ rung)
~1,000×	slipped a K/M/G — count the zeros again
~365×	mixed a day with a year on a storage ladder
~24×	mixed hours with days
~8×	mixed bits with bytes — networks speak bits, disks speak bytes
~5×	forgot the peak multiplier — you sized for the average
~3×	forgot replication — nobody stores bytes once

Notice something about that table: it is the section. The units guardrail, the pocket constants, the peak rule, the replication rule — every recurring mistake is a violated lesson, and the ratio tells you which one. Senior engineers sanity-check colleagues' numbers exactly this way: not by redoing the math, but by spotting a suspicious factor of 8 or 365 sticking out of a result. That skill — reading an estimate for its likely failure — is what this practice quietly installs.

And the twist you may have met in problem two: a whole year of a podcast platform — thousands of hours a day — fits on a couple of drives. Audio is ~60 MB/hour; video is ~5 GB/hour; that two-orders-of-magnitude gap is why the walkthroughs' video service lived in petabytes while your podcast empire lives in a shoebox. Dominant dimensions differ within media, not just between product types.

The miss decoder: an estimation error ratio names the exact constant you dropped. Within 2x of the reference you are right; off by a clean round factor is a fingerprint. ~10^5 = per-day vs per-second (dropped 1 day ≈ 10^5 s); ×1,000 = a K/M/G slip; ×365 = day vs year; ×8 = bits vs bytes (Mb ≠ MB); ×5 = forgot the peak; ×3 = forgot replication. Re-derive the ratio, never guess.

When You're Estimating for Real

One honest difference between this gym and the field: here, the givens were handed to you. In an interview or a design review, choosing the assumptions is half the skill — and it changes how correctness works.

There is no answer key. Your 50M DAU and someone else's 20M are both defensible; what's graded is that you said it out loud, wrote it down, and picked something plausible (anchored: "WhatsApp does 100B/day, we're a small fraction").
Ranges get wide — and that's fine. Two defensible assumption sets can produce answers 5× apart and both be useful, because the decision they feed ("one box or a fleet?") usually survives the spread. When it doesn't — when the decision flips inside your uncertainty range — that's the signal to stop estimating and go measure.
The process is the deliverable. Assumptions stated → ladder → units cancelled → peak applied → anchor checked → decision. An interviewer watching that sequence learns more from it than from the final number — which is why practicing the rungs, as you just did, transfers directly even though real problems come without answer boxes.

Keep the gym habit: any system you read about this week — a news story about some service's scale — run its envelope. Twenty reps of ninety seconds each and the reflex is permanent.

Key Takeaways & What's Next

Practice with feedback beats re-reading — paper first, check second, and treat every miss as a named lesson: ~10⁵ = day/second, ×8 = bits/bytes, ×5 = peak, ×3 = replication, ×365 = day/year.
The three dimensions behaved as promised: chat = pure rate (100K msg/s peak from 50M users), podcast storage = accumulation-but-tiny (audio's 60 MB/hr → ~130 TB/yr replicated), live sports = rate×size in bits (600 Gbps → 60 ports → CDN).
In the field, assumptions are yours to choose — state them, anchor them, and let the decision (not the digits) be the output. If the decision flips inside your uncertainty range, measure instead.

You can now produce the numbers. The final lesson of the section closes the loop: From Numbers to Architecture — what 100 QPS versus 100K QPS actually means for the shape of a system, so that every envelope you write from now on ends the way the walkthroughs did: with a design decision.