Module 01 · Core concepts · Lesson 3 of 9
Back-of-the-envelope estimation
Users to requests per second, requests to storage and bandwidth, in under three minutes. The dozen numbers worth memorising and the arithmetic shortcuts that keep estimates honest.
Why it matters
Architecture follows order of magnitude. A thousand requests per second is one well-tuned server and a managed database; a hundred thousand is a cache tier, sharded storage and a conversation about regions. If you cannot estimate the load in two minutes, every later decision is a guess, and interviewers notice. Estimation is also where you demonstrate numeracy about systems, which is rarer than it should be.
The idea
Start from a user number, convert to requests per second, then derive storage and bandwidth. Round aggressively; the goal is the exponent, not the mantissa.
The conversion that does most of the work
A day has 86,400 seconds. Call it 100,000. So one million requests per day is about 10 requests per second, and daily totals divide by 10^5 to give per-second averages. Peak traffic is typically two to three times average; use 3x for consumer products.
Numbers worth memorising
| Quantity | Value | Use it for |
|---|---|---|
| Seconds per day | ~10⁵ (86,400) | daily totals to per-second |
| Bytes | KB 10³ · MB 10⁶ · GB 10⁹ · TB 10¹² · PB 10¹⁵ | storage growth |
| Memory read | ~100 ns | why in-process caches are free |
| SSD random read | ~100 µs | database page reads |
| Same-region network hop | ~0.5 ms | every arrow on your diagram |
| Disk seek (HDD) | ~10 ms | why sequential writes win |
| Cross-continent round trip | ~100–150 ms | why CDNs and regions exist |
| One server, simple reads | ~1,000–10,000 rps | when to scale out |
| Postgres on good hardware | ~10,000 simple writes/s | when to shard |
| Compression | text ~5–10x, images ~1x | bandwidth and storage |
Storage and bandwidth
Multiply writes per second by the size of each record by seconds in the retention period. A tweet-sized record (about 300 bytes with metadata) at 1,000 writes per second is 300 KB/s, which is about 26 GB a day and roughly 10 TB a year. Media changes the picture completely: a single 2 MB photo per post at the same rate is 2 GB/s and 170 TB a day, which is why media goes to object storage and a CDN, not the database.
Bandwidth is the same multiplication applied to reads. 3,000 peak reads per second of a 100 KB page is 300 MB/s out, so an origin cannot serve it without a cache in front.
- 1
Write the inputs down
DAU, actions per user per day, read-to-write ratio, record size, retention. Ask for any you do not have. - 2
Convert to per-second
Divide daily counts by 10⁵. Multiply by 3 for peak. - 3
Derive storage
Writes per second × record size × seconds retained. Separate metadata from media. - 4
Derive bandwidth
Reads per second × response size. Compare with what one server can push. - 5
Say what the numbers imply
"Three thousand peak reads is one cache tier; ten terabytes a year is a sharded store within two years."
Trade-offs
Estimation trades precision for speed and should never take more than three minutes in an interview. The risk is false precision: quoting 2,314 requests per second signals you do not understand that the inputs were guesses. Round, say the exponent, and move on. The other risk is skipping it: without a number, you cannot justify a cache, a shard or a queue, and the interviewer cannot tell whether you would over-build or under-build.
In an interview
Do the arithmetic out loud and round visibly: "Ten million daily users, say ten reads each, that is a hundred million a day, about a thousand per second average, call it three thousand at peak. Reads dominate writes ten to one. Records are small, so storage is tens of gigabytes a year; the media is the real volume." Then use the numbers: every later component should be justified by one of them.
Check yourself
A service gets 500 million requests per day. Roughly what is the average and the peak load, using the standard shortcuts?