Estimation drills

Before designing a system, size it: how many requests a second, how much data, how many machines. The aim is the right power of ten in a minute, with round numbers you can multiply in your head. The estimation lesson explains the method.

7 questions, one of each kind. Within 2× counts as spot on; within 10× is the right order of magnitude.

Estimate: Requests a second

Practice, not recorded

A chat app has 500 million daily users, who each send 2 messages a day. About how many requests a second does it serve, on average?

Daily users: 500 million
Messages per user a day: 2

Estimate: Peak traffic

Practice, not recorded

A photo-sharing app has 1 million daily users, who each view 20 photos a day. Its busiest hour runs at 5 times the daily average. About how many requests a second must it handle at the peak?

Daily users: 1 million
Photos per user a day: 20
Peak ÷ average: 5×

Estimate: Storage a year

Practice, not recorded

50 million users each send 10 messages a day, 1 KB each. Everything is kept, and stored 3 times for safety. About how much storage does a year of them need?

Active users a day: 50 million
Messages per user a day: 10
Size of each: 1 KB
Copies kept: 3

Estimate: Latency budget

Practice, not recorded

A request must be answered within 200 ms. About how many main-memory references could it make one after another in that time, if it did nothing else?

Time budget: 200 ms
One of them (main memory (ram) reference): 100 ns

Estimate: Cache memory

Practice, not recorded

A database holds 1 billion product records, 1 KB each. As often happens, about 80% of reads go to the most popular 20%. How much memory does a cache need to hold that hot 20%?

Items stored: 1 billion
Size of each: 1 KB
Hot share: 20%

Estimate: Bandwidth

Practice, not recorded

A service sends 50,000 API responses a second, 2 KB each. About how much outgoing bandwidth does it need?

Responses a second: 50,000
Size of each: 2 KB

Estimate: How many servers

Practice, not recorded

At its peak a service gets 20,000 requests a second. One server can handle 1,000 a second flat out, but you want each to run at no more than 60% of that so latency stays low. About how many servers do you need?

Peak requests a second: 20,000
One server, flat out: 1,000
Target load per server: 60%

How to estimate

Write down what you know, with units: users, actions a day, bytes each.
Round everything to one significant figure or a power of ten. A day is about 10^5 seconds; a year about 400 days.
Multiply the powers of ten and the leading digits separately: 5 × 10^7 users × 20 = 10^9 a day, so 10^4 a second.
Provision for the peak, not the average, and leave headroom: servers run best well below 100%.
Sanity-check against something you know, such as a server handling a few thousand simple requests a second.

Three verdicts

Spot on: within 2×, all an estimate needs.
Right order of magnitude: within 10×.
Off: more than 10× out; the working shows the step that went astray.

Latency numbers to know

Approximate figures after Jeff Dean’s “Numbers everyone should know” (2009–2012) and Peter Norvig’s “Teach Yourself Programming in Ten Years”. Exact values depend on the hardware and have changed since; the powers of ten between the rows are what to remember.

Approximate latencies of common operations, fastest first
Operation	About
L1 cache reference	0.5 ns
Branch mispredict	5 ns
L2 cache reference	7 ns
Mutex lock and unlock	25 ns
Main memory (RAM) reference	100 ns
Compress 1 KB (Snappy)	3 µs
Send 1 KB over a 1 Gbps network	10 µs
Random 4 KB read from an SSD150 µs in the original list; current NVMe drives take tens of µs	~100 µs
Read 1 MB sequentially from memory	250 µs
Round trip within a data centre	0.5 ms
Read 1 MB sequentially from an SSD	1 ms
Disk seek	10 ms
Read 1 MB sequentially from disk	20 ms
Round trip California → Netherlands → California	150 ms