Back-of-envelope estimation

For this lesson, we'll cover the numbers worth knowing by heart, the four calculations that come up in almost every round (requests per second, storage, bandwidth and the read/write ratio), one fully worked example, and the part most guides skip: when to do the maths and when to leave it out. Interviewers ask for estimates less to test your arithmetic and more to see whether you can turn a number into a design decision.

01Picture it first: estimates are a decision tool

Here's the best short example I know, from a talk Jeff Dean gave at LADIS 2009. The question was how long it takes to build an image results page of 30 thumbnails. Reading them one after another, each needing a disk seek of about 10 ms plus the read, came out at roughly 560 ms. Issuing the 30 reads in parallel came out at roughly 18 ms, which he noted was really more like 30 to 60 ms once you allow for variance.

That's the attitude to bring into the room. You aren't producing a capacity plan. You're asking "is this one machine or a hundred?", "does it fit in memory?", "can one database take these writes?" A rough number answers each of those in under a minute.

02The numbers to know cold

You need three small tables in your head: powers of two for sizes, seconds in a period for rates, and latency orders of magnitude for "is this fast enough?".

Sizes: powers of two

In an interview, treat 1 KB as a thousand bytes and move on. The 2 to 13% error doesn't change any decision. The one place to be careful is bits versus bytes: network links are quoted in bits per second, so multiply bytes by 8.

Time: seconds in a period

• 1 day = 86,400 seconds. Round it to 100,000. It makes division trivial. It undercounts the per-second rate by about 14%, which the peak factor more than covers.
• 1 month ≈ 2.6 million seconds. 1 year ≈ 31.5 million seconds.
• Shortcuts that fall out of this: 1 million a day ≈ 12 a second; 100 million a day ≈ 1,200 a second; 1 billion a day ≈ 12,000 a second.

Latency: orders of magnitude

These come from Peter Norvig's table, Jeff Dean's LADIS 2009 slides and Colin Scott's interactive version, which models how they change over the years. Treat them as orders of magnitude, not benchmarks. Real hardware varies, and the sources disagree slightly (Norvig lists a disk seek at 8 ms, Dean at 10 ms).

What to take from it: a network hop inside the data centre costs about 5,000 RAM reads, so a design that makes ten sequential service calls per request has spent 5 ms before doing any work. And a user on another continent pays around 150 ms per round trip before your servers do any work, which is why you put content near them with a CDN.

Availability: what the nines allow

From the availability table in Google's SRE book: 99.9% allows about 8.76 hours of downtime a year, 99.99% about 52.6 minutes, and 99.999% about 5.26 minutes. Each extra nine cuts the allowed downtime by a factor of ten, and usually means more replicas, more regions and more automation. Use this when you write non-functional requirements, so "highly available" turns into a target you can design for.

03The four calculations

1. Requests per second. Daily active users x actions per user per day = requests a day. Divide by 100,000 for the average per second. Multiply by a peak factor for the busiest hour. I use 3 as a default and say it's an assumption; spiky products need much more (see the REAL block below).

2. Read/write ratio. Do the first calculation separately for reads and writes. The ratio shapes the whole design: read-heavy systems (100:1 or more) want caches, replicas and precomputed results; write-heavy systems want append-friendly storage, partitioning and queues to absorb bursts.

3. Storage. Writes a day x bytes per item x days kept. Split it by kind: small metadata rows (hundreds of bytes to a few KB) usually go in a database, while large blobs (images, video, files) go in object storage. Add replication on top if the interviewer cares: three copies triple the raw number.

4. Bandwidth. Reads per second x bytes per response gives egress. Multiply by 8 for bits per second. Ingress is the same calculation using writes and upload size.

04A worked example, start to finish

Here's how I'd lay it out on the board. Every row ends with the decision it drives; a number with no decision attached is wasted time.

A few things to notice. I used 100,000 seconds a day, so 2.5 billion became 25,000 a second (the exact figure is about 29,000; the decision is identical). I kept each line to one significant figure. And the photo storage line changed the architecture: at 7 PB a year, the question isn't "which database?", it's "object storage plus a metadata database".

05Peaks are where systems break

The average is a comfortable number. The peak is the one your system has to survive. A peak factor of 2 to 3 is a sensible default for products with smooth daily cycles. Products tied to live events can spike far higher.

So when the prompt involves live events (sports scores, ticket sales, flash sales, live comments), say so: "This is spiky. I'll design for 10 to 25 times the average, and plan to absorb bursts with a queue rather than provisioning for the peak all the time." See Queues and event streams for how that works.

06When estimates matter, and when to skip them

Estimates earn their minutes when the answer could go either way. Some decisions that depend on a number:

• One machine or many? If the write rate is 100 a second, one primary is fine. At 100,000, you're partitioning.
• Does it fit in memory? 10 GB of hot metadata fits in one cache node. 3.6 TB doesn't fit in one, so you'd shard it or cache only the hot slice.
• How long must the key be? The URL shortener needs 365 billion codes, so 6 base62 characters (about 57 billion) is too few and 7 (about 3.5 trillion) is enough.
• Do we need a CDN? Tens of gigabits per second of media says yes.
• Is this latency budget possible? Five sequential cross-region calls can't fit in a 200 ms budget at 150 ms each.

Skip the maths, or keep it to one sentence, when no plausible number would change the design. If the interviewer has already told you "assume Twitter scale", the conclusion (shard, cache, replicate) is obvious, and ten minutes of multiplication shows nothing new. Same if the interesting part of the problem is correctness, like a distributed lock, rather than volume. In those cases I'd say: "I'll assume roughly 100 million daily users and 10k requests a second at peak. I'll come back to the maths if a decision depends on it."

A few smaller traps worth avoiding:

• Forgetting the peak. Average QPS is not what you provision for.
• Mixing bits and bytes. 5 GB/s is 40 Gbps, not 5 Gbps.
• Doubling up precision. "28,935 QPS" sounds less senior than "about 30k", not more.
• Inventing hardware limits as facts. If you need "requests per server", say it's an assumption ("say one server handles a few thousand of these a second") and invite the interviewer to adjust it.

07How to say it in the interview

When I ask for an estimate, I'm listening for three things: clear assumptions, quick rounding, and a decision at the end. I don't check your arithmetic to the last digit. I do notice if 2.5 billion divided by 100,000 comes out as 2,500.