Checkpoint: Estimation & Numbers

Seven lessons ago, 'how fast is it?' was a question you'd answer with an average. Since then: you learned to read latency as a distribution (p50 tells you about everyone, p99 tells you the truth), to run the ninety-second ladder from users to peak QPS, to carry the 2026 number sheet in your head, to walk QPS, storage, and bandwidth end to end, to read any estimation miss by its error ratio — and to land every number on the band map as an architecture decision.

Time to find out if it compressed into a reflex. Ten situations below, pulled from production life and design reviews. Each has one move this section argues for and three that sound right — they are, precisely, the traps the lessons warned about: the trusted average, the forgotten peak, the ×8 units slip, the missing replication, the premature shard. No calculator needed anywhere — that was the whole point.

Everything the gauntlet draws on, one glance:

• Measure: latency is a distribution — mean describes no one; p50 moved = systemic, p99 moved alone = a tail problem. Target ~60–80% utilization; the knee is a cliff.
• Estimate: users → actions/day → ÷10⁵ → ×2–5 peak → decision. One digit and an exponent; year ≈ π×10⁷ s; reads:writes often 100:1 — say it out loud.
• Know: RAM 100 ns · SSD 150 µs · same-DC hop 500 µs · seek 10 ms · cross-continent 150 ms; ratios beat absolutes (DC hop ≈ 3 SSD reads); Postgres ~5–10K QPS · Redis 100K+ · nginx 10–100K; networks speak bits (÷8), storage replicates (×3), storage accumulates (×365).
• Decode a miss: ~10⁵ = day↔second · ×1,000 = K-slip · ×365 = day↔year · ×8 = bits↔bytes · ×5 = peak · ×3 = replication.
• Land it: bands, one per 10× — one box → a few boxes → the working fleet → queues-and-shards → planet scale. Transitions are named ceilings: availability → DB reads → writes → geography. Build for now, design for 10×, sketch 100×.

Read each situation as if it landed in your Slack. Commit to a move before you check — a wrong answer here, read carefully, is worth more than a lucky right one.

• 9–10. The chain is locked in: you can measure, estimate, price, decode, and land a number on an architecture. Go straight to the Capstone — it will use every link.
• 7–8. Solid. Look at which two you missed: both from the same lesson means one focused reread; scattered means you're fine — the distractors here are engineered from real failure modes.
• Below 7. Worth an honest hour before the Capstone. The highest-leverage rereads in order: the ladder (Back-of-the-Envelope Estimation), the number sheet (Numbers to Know), the band map (From Numbers to Architecture) — the other lessons hang off those three.

One meta-observation worth keeping: every wrong option in this gauntlet is something a real team has actually done — trusted the average, sized for the average, shipped the ×8 slip to a capacity plan, sharded a read problem, built Google at 150 QPS. The section's real gift isn't computing numbers; it's recognizing these moves in the wild, in your own designs and other people's.

This checkpoint closes the section — and the section closes the container's toolbox. You now hold: clients and servers, networks and protocols, availability and scaling, load balancing, databases and consistency, APIs, async and queues, caching and CDNs, and — as of this section — measurement, estimation, and the judgment to size a design honestly.

Next comes the payoff for all of it: the Capstone. A blank sheet, a realistic product brief — a marketplace — and no new concepts at all: just every tool in the box, used in anger, in the order a real design review would demand them. The envelope you'll write in its first ten minutes is exactly the one this section trained.