Estimation and the numbers to remember

Estimation sounds like maths. In a design discussion it is closer to reasoning with incomplete information: you do not need the exact answer, you need one that is close enough to change a decision.

Crux: estimate only what could change the design, work in round numbers and powers of 1,000, and check that the result is believable.

Why and when to estimate

Estimation shows that you can take a vague problem, make sensible assumptions and keep going. The person listening cares about your assumptions and structure, not about the last digit.

So do it where it matters. Find what makes the problem hard (the crux) and estimate there. Almost every design needs two things:

• Throughput of the bottleneck: reads and writes per second where it hurts.
• Total storage: how much data you keep.

It is a short step, about one to three minutes in a 35-minute session. Skip anything that would not change what you draw.

The five steps

• 1. Decide what to estimate. Pick the quantities that carry the load, such as peak requests per second or storage per year.
• 2. Break it into pieces you can solve. Chain units so they cancel (see below).
• 3. Start from what you know. Use numbers from the prompt, then numbers you remember.
• 4. Use round numbers. Prefer 1, 2, 5 and 10, and keep to powers of 1,000.
• 5. Sanity-check the answer. Compare it with something real. If it says a small app needs a million servers, an assumption is wrong.

When you are missing an input, make an assumption, say it out loud, and move on. A quick guess that the other person can correct is better than asking for the number up front.

Numbers to remember

This is the part to learn by heart. It is short on purpose.

Sizes: powers of 1,000

Each step up is 1,000 times bigger. Going up by a million means moving up two rows.

1 KB (kilo)  =  1,000 bytes          10^3
1 MB (mega)  =  1,000 KB             10^6
1 GB (giga)  =  1,000 MB             10^9
1 TB (tera)  =  1,000 GB             10^12
1 PB (peta)  =  1,000 TB             10^15

Computers actually count in powers of two (2^10 = 1,024), but 1,000 is close enough and far easier to multiply.

Time: seconds

1 day    = 86,400 seconds   ≈ 10^5  (round it to 100,000)
1 month  ≈ 2.5 million seconds     (30 days = 2.59 M)
1 year   ≈ 31.5 million seconds  ≈ 3 × 10^7

Two conversions follow from this and come up constantly:

Remember: 1 million per day is about 12 per second. And 1 per second is about 86,000 per day.

How big things are

1 character (ASCII)          1 byte
integer                      4 bytes
long, timestamp              8 bytes
UUID                         16 bytes
short text post (~140 chars) ~140 bytes
medium image / page graphic  ~100 KB
high-resolution photo        ~1 MB
small plain-text book        ~1 MB
two-hour movie               ~1 GB

To size a record, add up its fields and round up. A record of 123 bytes is "about 200 bytes" or even "about 500". The rounding error does not matter.

How long things take

For reading 1 MB sequentially: memory is about 0.25 ms, SSD about 1 ms (4 times slower than memory), and a spinning disk about 20 ms (20 times slower than SSD).

What to remember is the ratio, not the digits: memory is far faster than SSD, SSD is far faster than disk, and anything that crosses a network or an ocean costs milliseconds. Those figures come from a 2012-era list, and hardware is faster now, so use them for comparisons, not as benchmarks.

Availability: the nines

99.9%    ("three nines")   ≈ 8.8 hours of downtime per year
99.99%   ("four nines")    ≈ 53 minutes per year
99.999%  ("five nines")    ≈ 5 minutes per year

The arithmetic: a year has 8,760 hours, so 0.1% of it is 8.76 hours. Every extra nine divides the allowed downtime by ten.

How big real products are (order of magnitude)

daily active users, a major social network    ~1 billion
hours of video Netflix streams per day        ~100 million
Google searches per second                    ~100,000
size of Wikipedia                             ~100 GB

These are rough, from a 2023 article. They are only good for knowing whether you are in the thousands or the billions.

A worked example: the link shortener

The inputs below are assumptions for practice, not facts about any real service. Say each one aloud.

Assume: 100 million new links a month, and 100 reads for every link created.

Writes:   100 M links / month  ÷  2.5 M s / month        ≈ 40 writes / s
Reads:    100 reads per write × 40                       ≈ 4,000 reads / s
Peak:     assume 3× the average                          ≈ 12,000 reads / s

Now storage. Size one record by adding the fields:

Record:   code 7 B + URL ~100 B + owner 8 B + time 8 B   ≈ 123 B  →  round to 200 B
Links:    100 M / month × 12                             = 1.2 B links / year
Storage:  1.2 B × 200 B                                  = 240 GB / year   (~1.2 TB over 5 years)

The link table is small. But we also store a click for every redirect:

Click record: ~100 B  (assumed)
4,000 clicks / s × 100 B  = 400 KB / s
400 KB / s × 86,400 s     ≈ 35 GB / day   →  ~12.6 TB / year

Sanity check: 240 GB a year for links is believable, and clicks are far bigger because there are 100 reads for every write.

What the numbers decide:

• The link table fits on one machine for years, so storage does not force sharding.
• Reads are the load. 12,000 per second at peak is a good reason to cache hot codes and add read replicas.
• Clicks dominate storage and are written at the read rate. That is the real hard part, and it is where the deep dive should go.

Notice that none of this needed exact figures. It only needed enough accuracy to point at the right problem.

From numbers to decisions

A number is only useful if it changes what you draw. These pairings come up again and again:

• Reads far outnumber writes → cache and read replicas.
• Writes are heavy or bursty → a queue, batching, or sharding.
• Data is larger than one machine → shard it. If it is not, do not.
• Latency budget is tight → keep data in memory, near the user.
• Peak is much higher than average → plan for the peak, or buffer it.

These are rules of thumb, not thresholds. Modern machines can hold a lot of fast storage, which makes single-server designs more viable than people expect, so it is worth saying so.

Common mistakes

• Estimating things that do not matter. If it would not change the design, skip it.
• Getting lost in arithmetic. Round early. 86,400 is 100,000.
• Being off by orders of magnitude. A 20% error is fine. A 1,000x error means a bad assumption or a unit slip, so go back.
• Mixing units. Bits and bytes, per day and per second, MB and GB.
• Using average load for a peak problem.

Practice

Start with everyday questions and then check yourself, so your instincts calibrate. How many emails do you get in a week? How many steps do you walk in a year?

Then try these:

• A service has 10 million daily users, and each makes 20 requests a day. About how many requests per second? (10 M × 20 = 200 M a day; ÷ 100,000 ≈ 2,000 per second on average.)
• How long does it take to read a 1 GB file sequentially from an SSD? (1 GB is about 1,000 MB, at about 1 MB per ms, so about 1 second. From memory, about 0.25 s. From a spinning disk, about 20 s.)
• A photo app stores 1 MB per photo, and 1 million photos are uploaded a day. How much storage per year? (1 TB a day × 365 ≈ 365 TB, so roughly 0.4 PB.)

The one-page cheat sheet

Redraw this from memory a few times. It is the whole lesson on one page.

Check yourself

• Why is "I'll estimate everything first" a mistake?
• What do you do when you are missing an input?
• How many seconds are in a day, rounded, and how many requests per second is 1 million a day?
• Put these in order, fastest to slowest: disk seek, memory reference, same-datacenter round trip, SSD read of 4 KB.
• How much downtime does 99.99% availability allow in a year?
• In the link-shortener example, which number pointed to the deep dive, and why?