Numbers to Know
A compact reference of rounded latencies, sizes, time conversions, server capacities and availability nines, each with how it gets used in an estimate.
On this page
A candidate designs a checkout page with a 200 ms budget. To show a price it calls a tax service, then a stock service, then a fraud service, one after another, and all three live in another region. Each call is a round trip of about 100 ms, so the page takes over 300 ms before it does any work of its own. Nobody computed it until the interviewer asked.
You need about twenty numbers, each right to within a factor of 3, and the habit of using them. Every number below is rounded and approximate: real values depend on hardware, distance and load. State them as assumptions.
Latency
| Operation | About | Use it to |
|---|---|---|
| Read from main memory | 100 ns | Show an in-process lookup is free next to any network call. |
| Random read from an SSD | 100 µs (0.1 ms) | See that in an indexed read of a few ms, the network and the database's own work cost more than the disk. |
| Round trip within one data center | 0.5 ms | Price a call to a cache or another service nearby. |
| Round trip between zones in one region | 1 ms | Price synchronous replication to another zone. |
| Indexed database read, over the network | 1 to 10 ms | Count how many reads a request can afford. |
| Disk seek on a spinning drive | 10 ms | Explain why spinning disks suit sequential logs and backups, not random reads. |
| Round trip between regions or continents | 50 to 150 ms; use 100 | Keep cross-region calls off the request path. |
The ratios matter more than the values. A same-region call is about 5,000 memory reads; a cross-region call is about 200 same-region calls. Step through one request and watch where the time goes.
- elapsed
- 0 ms
- budget
- 200 ms
1The clock starts when the request reaches the app server. It checks a config value in its own memory: about 100 ns, which rounds to nothing.
- elapsed
- 0.5 ms
- budget
- 200 ms
2It asks the cache for the cart, one round trip in the data center. Miss.
- elapsed
- 5.5 ms
- budget
- 200 ms
3It reads the cart from the database, an indexed read of about 5 ms.
- elapsed
- 105.5 ms
- budget
- 200 ms
4It calls the tax service in another region: 100 ms. That one call costs about 18 times everything before it.
- elapsed
- 1,005.5 ms
- budget
- 200 ms
5Now the link to that region degrades. The call hangs until a 1-second timeout fires, and every checkout misses its budget fivefold.
- elapsed
- 6.5 ms
- budget
- 200 ms
6The fix: copy the tax tables into this region and read them locally, about 1 ms. The cost: an update reaches this copy after a short delay.
| Option | Good at | Bad at | Pick it when |
|---|---|---|---|
| In the app server's memory | About 100 ns. | Each server has its own copy, so updates spread slowly; limited by one server's memory. | Small, rarely changing data, or a few extremely hot keys for a few seconds. |
| Shared cache, same region Usual default | About 0.5 ms, and one copy for all servers. | Another component to run, and stale entries to manage. | Hot reads that many servers share. |
| Database in the region | The source of truth; 1 to 10 ms. | The most expensive reads to scale. | Anything that must be current, and every cache miss. |
| Another region | One copy for the world. | About 100 ms per round trip, and it fails when the link does. | Off the request path only: background sync, replication. |
Sizes and throughput
- Small values: an ASCII character 1 byte, an integer or timestamp 8 bytes, a UUID 16 bytes, a typical metadata row 100 bytes to 1 KB.
- Media: a compressed photo a few hundred KB to a few MB. Video at 5 Mbit/s is 5 ÷ 8 × 60 ≈ 40 MB a minute.
- Powers of two: 210 ≈ a thousand, 220 ≈ a million, 230 ≈ a billion. 232 ≈ 4.3 billion is where 32-bit IDs run out, so use 64-bit IDs for anything that could pass a few billion rows. The estimation lesson has the full table.
- Throughput: memory about 10 GB/s, SSD about 1 GB/s, a 10 Gbit/s network link about 1.25 GB/s. Use these to price copies: rebuilding a replica, a backup, a reshard.
A database node dies. How long does copying its 1 TB to a new node take, if the network is the limit?
- 1 TB of data
- A 10 Gbit/s link, fully used
- 1 byte = 8 bits
Show the working
- 10 Gbit/s ÷ 8 = 1.25 GB/s
- 1012 B ÷ 1.25 × 109 B/s = 800 s
- 800 s ÷ 60 ≈ 13 minutes
Estimate 13 minutes (anything from 5 minutes to 40 minutes is a good answer)
For those 13 minutes or more, that partition has one fewer copy. It is why you keep three, not two.
Time and capacity
A day is 86,400 seconds, about 105. A month is about 2.6 million seconds, a year about 31.5 million. So 1 million events a day is about 12 a second; call it 10 and say you rounded down.
Single-server capacities vary by ten times or more with hardware and query shape, so treat these as orders of magnitude to state and check with the interviewer:
- A stateless API server: about 1,000 requests a second for typical work.
- A relational database primary: a few thousand writes a second; reads by index into the tens of thousands.
- An in-memory cache node: about 100,000 simple reads a second.
- Open connections on one server (WebSockets): tens of thousands, up to about 100,000 mostly idle ones.
- One large machine: hundreds of GB of memory and a few TB of SSD. If your data set fits, say so: one machine is the simplest design.
Availability
| Target | Down per 30-day month | Down per year |
|---|---|---|
| 99% | 7.2 hours | 3.7 days |
| 99.9% | 43 minutes | 8.8 hours |
| 99.99% | 4.3 minutes | 53 minutes |
| 99.999% | 26 seconds | 5.3 minutes |
Use it two ways. Parts that must all work multiply: three services at 99.9% each give 0.9993 ≈ 99.7%, about 2 hours down a month. Redundant copies, where any one is enough, multiply their downtime instead: two copies at 99% give 1 − 0.012 = 99.99%, assuming they fail independently, which shared power or a shared bad deploy can break. More in reliability and failure.
The target is 99.95% availability. How much downtime does that allow in a 30-day month?
- 30 days × 24 hours × 60 minutes = 43,200 minutes
- Allowed downtime is 100% − 99.95% = 0.05%
Show the working
- 43,200 × 0.0005 = 21.6 minutes
Estimate 22 minutes (anything from 10 minutes to 45 minutes is a good answer)
A single failover that takes 5 minutes uses almost a quarter of the month's budget, so failover must be automatic.
In the interview
Bring a number in whenever a decision rests on speed, size or uptime, and finish with "so":
- "A cross-region call is about 100 ms, so it can't be on the checkout path."
- "50 million users at 1 KB each is 50 GB, so the sessions fit in one cache node's memory, with a replica."
- "99.99% is about 4 minutes a month, so no manual step can be in failover."
Could we keep one database in the US and serve European users from it?
Each round trip from Europe is around 100 ms. A page that makes three sequential reads would spend 300 ms just waiting. So I'd serve reads from a European replica and accept a short replication delay, and keep writes in the US if they're rare, sending a user's reads there for a few seconds after they write so they see their own change.
Follow-ups you should expect:
- "Why can't cross-region be faster?" Light in fibre covers about 200 km per ms. New York to London is about 5,600 km, so a round trip takes at least 2 × 5,600 ÷ 200 = 56 ms before any routing.
- "Where does 1,000 requests a second per server come from?" "It's an assumption for typical work. I'd load test, and the design doesn't change if it's 3,000."
Common mistakes
A page makes 4 sequential calls to a service in another region, and each needs one round trip. Roughly how long does the page spend waiting?
A request needs three services in a chain, each 99.9% available. About how available is the request?
Hot product data is read on every request by 50 app servers and changes a few times a day. Where should it live?
What to practise next
Put the numbers to work in Mock Interview Practice, or see latency drive a full design in Design Typeahead Search.