Back-of-the-Envelope Estimation

In one line

You think this chapter teaches you to get the numbers right. What it actually teaches is how to compress an open-ended question into an order of magnitude using a chain of assumptions you say out loud. The deliverable was never the number — it is a chain anyone in the room can knock down on the spot. Being off by 2× costs you nothing; being off by 1000× means your whole architecture rests on a false premise.

Glossary

Where it sits

This is the second chapter of Part I, "the method and the basics", wedged between two others: Ch1 gives you the parts and the order to install them (add a cache, add replicas, shard…), and Ch3 gives you the interview process (clarify → high-level design → deep dive → wrap up). Ch2 supplies the piece in between — how you decide which step you are actually at. It is the shortest chapter in the book, and it is the fixed opening move that all twelve later case studies (rate limiter, URL shortener, YouTube, Google Drive…) re-run from scratch.

What the chapter is solving

An interviewer says "design an X", and the second sentence is almost always "roughly how many users, how much data?". That isn't a trap. It's because architecture is meaningless without a scale attached: the same feature at ten thousand requests a day and at ten billion requests a day has completely different right answers — one machine and a database for the first, sharding and multi-region object storage for the second.

What happens without an estimate? Both directions fail, and both are common. Overshoot: five thousand users, but the team has already sharded the database and gone multi-region, so most of the engineering time goes into infrastructure — and sharding is close to irreversible. Undershoot: the design review says "we'll put it in the database", and after launch it turns out to be 30 TB of new data per day. That isn't a bigger disk; that's rebuilding the storage layer.

The subtler third failure is estimating only the average. A service with 1M DAU and 10 requests per user per day averages about 116 QPS — sounds trivial. But traffic is never flat, and 8pm may be several or several dozen times the mean. A system sized to the average is guaranteed to fail at the exact moment it matters most.

So the chapter builds exactly one skill: given a few assumptions about user behaviour, get QPS, storage and bandwidth right to an order of magnitude — on a whiteboard, in three minutes, without a calculator.

The core content, properly

Table one: powers of two — where every capacity estimate starts

Estimating storage is always the same multiplication: size of one record × records per day × days retained. So the first requirement is converting data units in your head. The book's reference points are plain: an ASCII character is 1 byte; 2^10 ≈ a thousand, i.e. 1 KB; 2^20 ≈ a million, 1 MB; 2^30 ≈ a billion, 1 GB; 2^40 is 1 TB; 2^50 is 1 PB.

Trivial-looking, but it turns straight into judgement. The book breaks a tweet down as: tweet ID 64 bytes + text 140 bytes + media 1 MB. Look at how lopsided that is: the text is two hundred bytes, the media is five thousand times larger. That single ratio hands you the whole storage strategy — text is free, media is the bill. Real systems put text in a database and media in object storage behind a CDN because of this ratio, not because of architectural fashion.

Table two: latency numbers — an engineer's sense of scale

The second table is the soul of the chapter, and it comes from Google's Jeff Dean; the industry knows it as "latency numbers every programmer should know". The point isn't to recite it. The point is that when you hear a design, you immediately feel which order of magnitude it lands in.

The book reads five conclusions straight off this table, each one an actionable design rule: memory is fast, disk is slow; avoid disk seeks where you can; simple compression is cheap (1 KB costs 10 µs); compress before sending over the network; datacenters live in different regions and moving data between them takes real time.

Rules three and four combine into something very practical: compressing 1 KB costs 10 µs, a transcontinental round trip costs 150 ms — a factor of fifteen thousand. "Compress first, then send" is almost always worth it, and that isn't folklore; it's arithmetic you can do by putting two numbers side by side.

Table three: the nines — turning "reliable" into a checkable promise

The third table converts the adjective "highly available" into concrete downtime. It matters because each additional nine typically costs exponentially more while buying you only a few more minutes a month — and you can only judge that trade once both sides are numbers.

Table 1 · Availability target ↔ allowed downtime (the book's table, four common tiers)

The insight is in the gap between the middle rows. Going from 99.9% to 99.99% buys you 39 minutes a month. Thirty-nine minutes is not enough for a human to be paged and restart something — which means it has to come from automatic failover, and therefore from redundancy, health checks and drills. The book notes explicitly that the major cloud providers (Amazon, Google, Microsoft) offer SLAs of 99.9% or above, and that an SLA is never 100%.

A full worked estimate: Twitter's QPS and storage

The book ties the method together with one example, with every assumption stated out loud: 300 million MAU; 50% use it daily; 2 tweets per user per day; 10% of tweets carry media; data retained for 5 years.

Unpacked, the traffic branch is two steps: 300M posts divided by the 86,400 seconds in a day is about 3,500 QPS; times two gives a peak of roughly 7,000 QPS. The storage branch is also two steps: 10% of 300M posts at 1 MB each is 30 TB per day; times five years is about 55 PB.

The value is in the last step — translating numbers into decisions. 7,000 QPS says one database won't do, but it is nowhere near "must shard" territory: a cache and read replicas cover it. And the moment 55 PB appears, "store media in the database" is off the table, object storage plus a CDN becomes the only sane answer, and cost overtakes performance as the binding constraint. Those two sentences are what the chapter exists to deliver.

The peak: the most fragile assumption in the chapter

That "× 2 for peak" step is the link in the chain most deserving of suspicion. Two is a convenient default, but the shape of a traffic curve is set by the business, not by a formula. Twitter's own published numbers show how wide the gap can get.

So the right move is not to swap in a bigger constant. It is to list the multiplier as an explicit assumption with a stated basis — "from our last twelve months of traffic, peak runs about 6× the mean". A justified 6× beats both an unjustified 2× and an unjustified 25×.

Three techniques: why "write it down" beats being good at arithmetic

The chapter closes with three practical techniques. They look mundane; each blocks a specific class of mistake.

Rounding and approximation. No hard arithmetic on a whiteboard: treat 99987 / 9.1 as 100000 / 10. This is not sloppiness — your inputs were assumptions to begin with, and running low-precision inputs through high-precision arithmetic only produces a precise wrong answer.

Write down your assumptions. This is the most important of the three, because it changes what kind of conversation you are having. With the assumptions on the board, a review moves from trading guesses to "change daily-active from 50% to 20% and run it again". The output of an estimate is a re-runnable chain of reasoning, not a number. Interviews work the same way: interviewers rarely correct your arithmetic, and they almost always challenge your assumptions.

Label your units. Writing 5 means nothing; write 5 MB. The book calls this out separately because unit confusion — MB for Mb, per-day for per-second — is the most common and most lethal error in estimation. A single slip is worth a factor of 8, or of 86,400.

The book also lists the five estimates that come up most: QPS, peak QPS, storage, cache size, and number of servers. Those five cover the opening of essentially every "design an X" question.

Key trade-offs and choices

The trade-off here isn't "which technology". It is "how precise is precise enough" and "which architecture tier does this magnitude imply".

Table 2 · The five common estimates: how to compute them, and where they go wrong

Table 3 · Magnitude → what to do (tiers are common industry rules of thumb, not from the book; real thresholds vary widely with hardware and workload)

What Table 3 is really saying is not these particular numbers — it's that the magnitude → action mapping should exist in your head at all. The most convincing sentence in an interview or a design review is: "on my assumptions peak is around ten thousand, so at this tier a cache and read replicas are enough and I'm not going to shard yet." Whether the conclusion hangs off a number is the clearest line between a novice and someone who has done this.

Why it matters / in real systems

This method earns its own chapter because it is the only tool that makes an open-ended question converge. Without a magnitude, "design a URL shortener" can run an hour. With one, the discussion collapses onto a few concrete constraints: 100:1 read/write, 10k peak QPS, 3 TB over five years. The items below are not the book's claims — they are what these companies and authors published themselves:

Pitfalls and disputes

• Precision worship: treating the estimate as an arithmetic contest, agonising over 3,512 versus 3,500. Nobody in a review or an interview cares. An order of magnitude is an error; a factor of two is not.
• Copying the 2× peak multiplier: the number in this chapter most deserving of suspicion. Twitter's real record was 25×. For anything driven by sales, ticket drops, live streams or news events, derive the multiplier from your own historical curve; it doesn't transfer.
• Estimating the mean and never the tail: a system with a beautiful average may be delivering nothing but p99 to its users. The more a request fans out, the more the tail is amplified (see the 63% figure above).
• Storage estimates that omit copies and overhead: 55 PB is the raw figure. Real clusters usually keep three replicas, plus indexes, metadata and scratch space — the purchase order tends to be two to three times the raw number. This is the most common and most expensive omission in the whole exercise.
• Unit errors: MB versus Mb (bytes versus bits) is a factor of 8; "per day" versus "per second" is a factor of 86,400. The book devotes a whole technique to labelling units, and it isn't being fussy.
• Treating estimation as a substitute for load testing: it gives you a magnitude and can never answer "will this code hold?". Real bottlenecks routinely appear where the estimate doesn't look — lock contention, connection pools, GC pauses. Estimation sets direction; load tests settle the question.
• A dated table: the latency numbers are from the spinning-disk era (10 ms seeks). Today's NVMe SSDs do random reads in the hundreds of microseconds, compressing "disk is slow" by about two orders of magnitude. But the table's real value is the relative ordering — memory ≪ local disk ≪ same-datacenter network ≪ transcontinental network — and that ordering has not changed, because the last gap is set by the speed of light.
• One dispute: estimation has become somewhat ritualised in interviews, with some interviewers checking only that you did it rather than whether the assumptions were sensible. That is not a flaw in the method. The dividing line is still whether you translated a number into an architectural decision, not whether you filled a whiteboard with multiplication.

Takeaways