Back-of-the-envelope estimation

Why estimate at all

You do not need exact numbers. You need to know the order of magnitude: is it 100 requests per second or 100,000? Is the data 10 GB or 10 PB? Those answers change the architecture completely, and you can get them with simple arithmetic.

Numbers to remember

Powers of two for sizes:

Unit	Approx. size
1 KB	a thousand bytes
1 MB	a million bytes
1 GB	a billion bytes
1 TB	a trillion bytes
1 PB	a thousand TB

Time: one day is about 86,400 seconds, which we round to 100,000 (10^5) to make mental maths easy.

Rough latencies (the exact values change with hardware, the ratios matter):

Operation	About
Read from memory	100 ns
Read 1 MB sequentially from memory	tens of microseconds
SSD random read	100 microseconds
Round trip inside one data center	0.5 ms
Disk seek	10 ms
Round trip across continents	100 to 150 ms

Two lessons fall out of this table: memory beats disk by orders of magnitude, and crossing a network or an ocean is expensive, so avoid unnecessary round trips.

A method

1. Start from users: daily active users (DAU).
2. Actions per user per day, giving total requests per day.
3. Divide by 100,000 for average requests per second (QPS).
4. Multiply by 2 to 5 for peak QPS.
5. Size per item times items per day gives storage per day; multiply by retention and replication.

The method as a picture

100%

Figure SDA-FND-03-1 · From users to requests and storage · © forcsguy.com

Worked example: a short-link service

• 100 million new links per month.
• Reads outnumber writes 10 to 1.

Writes per second: 100,000,000 / (30 x 86,400) is about 40 per second. Reads: about 400 per second. Peak maybe 2,000 reads per second.

Storage: each record is about 500 bytes (the short key, the long URL, a date). 100 million per month x 12 months x 5 years = 6 billion records x 500 bytes = 3 TB. Easily one modern database over a few years, with replicas for safety.

What did we learn? The write rate is tiny, reads are modest, and the whole data set is small. This is not a problem that needs exotic technology, so the design should be simple. That conclusion is the point of estimating.

100%

Figure SDA-FND-03-2 · Turning users into load and storage · © forcsguy.com

Rules of thumb

• Round aggressively. 86,400 becomes 100,000. 2.7 becomes 3.
• Write units next to every number. Most mistakes are unit mistakes (bits versus bytes, MB versus GB).
• State your assumptions. If someone disagrees with 10 requests per user, you can change one number and recompute.
• Sanity check against reality. If your estimate says a small app needs a million servers, an assumption is off.

Real-world reading