Back-of-the-Envelope Estimates

8:10 pm on the night of a cricket final. On a food delivery app, the checkout button spins and then fails for nearly two of every three orders. The dashboards are puzzling: the checkout servers’ CPUs sit at 25%. The team had sized checkout for an ordinary Friday dinner, with room to spare. Tonight orders arrive twice as fast, and the payment gateway, swamped by every other app, takes 3 seconds a call instead of 1. All 200 checkout threads are waiting on it. Nothing is broken. Two numbers multiplied together a week earlier would have shown that 200 threads could never cover tonight.

An estimate turns vague words like "lots of users" into numbers you can design against: requests per second, storage, bandwidth, servers and money. Engineers make them before a launch, before a sale or a final, in design reviews, and when a cloud bill jumps. You need the right order of magnitude (the nearest power of ten), not an exact answer, because designs change at each factor of ten. As a rough guide:

Each band starts from a different number: reads bring a cache, writes bring sharding, file sizes bring a blob store. The rest of the chapter sizes the food app for its final night, one number at a time.

Estimates happen in design reviews, chat threads and capacity plans, usually without a spreadsheet, so make the arithmetic easy. Round every input to one or two significant figures and work in powers of ten: 86,400 becomes 10⁵, and 2.6 million becomes 2.5 × 10⁶.

Then write each assumption down before you use it: "20 million daily users, 30 requests each." A reviewer can correct one input without redoing your work, and when real traffic arrives you can see which assumption was wrong. Five habits keep the arithmetic honest:

• Write the formula first, then put numbers in, keeping the unit on every value.
• Keep reads and writes separate. They often differ by 10× or 100× and are handled by different parts.
• Round in whichever direction keeps the maths easy, and note which way you rounded.
• Sanity-check the result against something you know: does 20 PB sound like a startup or a giant?
• Work out only the numbers that change a decision; replace the rest with a stated assumption.

Where real numbers exist, use them: last month’s peak requests per second, bytes per request from the logs, a load test of one server. The formulas stay the same; only the inputs get better.

Every storage and bandwidth estimate starts from units and the size of one item. Computers count bytes in powers of two, but powers of ten are easier to multiply, and 2¹⁰ = 1,024 is within 3% of 10³, so each unit is roughly a thousand times the last.

Strictly, 1,024 bytes is a kibibyte (KiB). The gap grows to about 13% at a petabyte, less than the usual error in an estimate. Indian numbers need one more conversion: 1 lakh = 10⁵, 10 lakh = 10⁶, 1 crore = 10⁷ and 100 crore = 10⁹. Convert before multiplying; switching systems halfway is a classic slip.

These item sizes are worth knowing by heart. The food app’s own items sit in the middle of the table; when unsure, round up and say so.

Two habits make the table useful. Count the metadata (ids, timestamps, indexed fields): in a 100-byte ping, the position itself is only 16 bytes. And check media against a bitrate: 5 Mbps is 5 ÷ 8 ≈ 0.6 MB a second, so a minute is about 40 MB.

With sizes in hand, the next conversion is time. A day has 86,400 seconds. Round it to 10⁵ and any per-day count becomes a per-second rate by dropping five zeros. The answer comes out about 14% low, well inside estimation error.

The first row is the one to memorise: a million a day is about a dozen a second. Every other row is the same fact with zeros added. For the food app, 2 million orders a day is about 23 a second, and 600 million requests a day about 7,000. Working backwards is just as quick: 500 requests a second is roughly 40 to 50 million a day.

Rates say how much work arrives; the latency ladder says how long each piece takes, which depends on where the data lives. You need the ladder in your head, not exact figures. To make the gaps feel real, the last column stretches time so that 1 nanosecond becomes 1 second.

The lessons fall out of the ladder. Memory is about 1,000× faster than an SSD, which is why caches exist: the food app’s menu cache answers in under a millisecond from the same data centre, while a database query that misses it costs tens of milliseconds. One cross-continent round trip costs as much as 400 inside a data centre, so keep chatty calls inside one region and put data near users.

Real hardware varies. A fast NVMe drive beats 100 µs, and a busy network is far slower than 0.5 ms. Quote these figures as orders of magnitude, which is all an estimate needs.

With units and time settled, the most common estimate is QPS (queries per second, used loosely for requests per second). Build it from users and their actions rather than guessing the final number:

Split reads from writes: the food app’s users browse dozens of menu pages for every order they place, and the two sides are handled by different parts. Then multiply by a peak factor, the ratio of the busiest minutes to the daily average. These are assumptions to state, not laws:

Choose the factor from the product’s own peaks, and measure it once you have history, per minute rather than per hour: an hourly average hides a first-minute spike that can be several times higher. For the food app, 600 million requests a day averages about 7,000 a second, an ordinary Friday dinner peaks near 4× that, and a final night doubles the Friday rush. The average describes almost no real minute, so design for the peak, not the daily average.

Now put the pieces together for the night that broke checkout. A week ahead, while there is still time to add machines, the team asks one question: how many app servers does the final need?

Sized for the average, the app would get 10 servers; the final needs 80, and an ordinary Friday about 40. With the exact 86,400 the peak is about 56,000 a second, and 80 servers would run near 70% busy instead of 60%: still inside the target, which is why the rounding is safe here.

The same inputs size the writes, and they hold a surprise:

The biggest write stream is not orders but rider pings, about 30 times the order writes. Each stream will end up in a different place, and the capacity page later decides where.

Requests come and go; storage stays. Every write adds to it, and it rarely shrinks:

Copies is the factor people forget: many stores keep three copies of every piece of data, and backups add more. A database adds two further factors: indexes, often 30 to 50% on top of the rows, and headroom, because disks should stay under about 70% full. Multiplying by 1.5 and dividing by 0.7 roughly doubles the disk.

Of the four factors in the formula, days kept (the retention) is the one the team chooses. The food app’s product team asks to keep every rider ping for five years, "in case we need it".

Kept five years, pings need nearly a petabyte, more than ten times everything else the app stores. Kept 30 days, they fit on a few machines. Set retention per kind of data: raw pings for 30 days, a short summary of each trip’s route for years, orders for as long as accounting needs them.

Growth compounds on top. If pings grow 50% a year, the fifth year alone adds more than the first three combined, so state a growth rate or plan to re-estimate every quarter.

Storage counts bytes kept; bandwidth counts bytes moving each second, and it is one more multiplication:

Traffic coming in (ingress) is mostly writes and usually small: the food app’s 60,000 pings a second at 100 bytes are 6 MB a second, about 48 Mbps. Traffic going out (egress) is mostly reads, and media makes it large. Dish photos show how:

Links are sold in bits per second, so multiply bytes by 8; mixing the two puts you off by 8×. Sixty gigabits a second would keep three to six network cards running flat out at the origin, which is why photos go through a CDN, a network of servers near users that keeps copies of files. If the CDN answers 95% of requests, the origin serves only about 3 Gbps at the peak.

The balance flips for products that mostly upload, such as phone backups or video uploads: there ingress is the big number, so estimate both directions. Cloud providers bill egress per GB, so this number also lands on the bill, which the money page prices.

Once the peak is known, servers are a division. The hard part is the per-server figure, which depends on how much work each request does, so pick a plausible number and state it: for example, one app server handles about 1,000 requests a second of light JSON work with a cache lookup.

The target utilisation (60% here) is the busiest you let a machine get at the peak, and it buys two things. Room for failure: if 10 of the 80 servers die, the rest run at 69%. And short queues: in a simple queueing model, a request’s time in a server is its service time ÷ (1 − utilisation), 2.5× at 60% but 20× at 95%. A fleet sized at 95% to save money tips over when one machine fails.

Cache memory is a size estimate. The food app’s 300,000 restaurant menus, without photos, average about 20 KB each: 6 GB, which fits in one cache node’s memory, so cache all of it, with a replica for failover. When a dataset is too big, a small share of items usually gets most reads, often summed up as 80/20: cache the hottest 20% and most reads still hit.

Every sizing ends in the same division: the load you estimated ÷ what one component can take. These figures are rough, for modern hardware and simple operations; heavy queries or large payloads can cut them by 10×.

IOPS means input/output operations per second; a log partition is one ordered slice of a replicated log, covered in Message Queues. Here is the table deciding where the food app’s data lives:

Notice what did not happen: no sharding. A standby replica covers the primary’s failure, and moving orders older than a year to cheaper storage keeps each copy near 3 TB, so a restore at 500 MB a second takes under two hours instead of most of a day. The plan holds until order writes near 10,000 a second.

Requests per second is a rate, but many limits are counts: threads, database connections, open sockets. Little’s law links the two: the number in flight equals the arrival rate times the time each one spends inside. It explains the night checkout broke.

On an ordinary Friday, 92 orders a second × 1 s kept 92 threads busy, under half the pool. On the final, 185 a second × 3 s needed 555. A slow dependency shows up first as a full pool, long before any CPU looks busy, and a timeout caps the time inside, so it also caps the pool you can ever need.

The same law counts connections. Customers keep a live tracking screen open for about 40 minutes per order, so at 185 orders a second about 185 × 2,400 ≈ 450,000 screens are open: five connection servers at 100,000 sockets each, eight with headroom.

Requests, storage, bandwidth and servers are four estimates. The fifth is money, and often one line is enough: which part of the bill dominates. Run it before any launch that changes what users download. Use rough list prices and check current ones: they change, and large customers pay less.

The food app’s product team wants a 10-second video of each dish that plays by itself as users scroll a menu. Here is the cost check, assuming 20 autoplays per user a day at 1 Mbps and egress at the low end of the range:

Two things stand out. Serving costs far more than storing: the photos cost about 500× more to deliver than to keep. And autoplay would multiply the delivery bill about seven times before it earns a rupee. The design follows the bill: tap-to-play or Wi-Fi-only videos at a lower bitrate, and a CDN rate negotiated before the launch, not after.

Before an estimate goes into a design doc or a capacity plan, check it for the usual errors. Most are not arithmetic slips but missing factors, and each one costs a predictable multiple:

Three checks catch most of the rest. Test the extremes: if your answer means each user uploads 1 GB a day, an input is wrong. Compare with production once it exists: last month’s real peak beats any assumed factor. And use the result: an estimate that changes no decision was not worth making.

In a 45-minute design round, estimates get about three of the 40 design minutes, so work out only the numbers that change a decision and say each assumption before you use it.