Learn
Back-of-the-envelope estimation: the numbers every system design starts with
Every design question starts with the same arithmetic: how many requests per second, how much data, how big a cache. You don't need precision, you need the right order of magnitude, quickly. This page has the formulas, the numbers worth remembering, and a calculator that shows every step.
· 3 min read
Estimate from daily users
- 10M users × 10 = 100M requests/day
- ÷ 86,400 seconds = 1,157 req/s on average
- × 2 in the busiest hour = 2,315 req/s at peak
- 1% writes = 23 writes/s at peak, 1M new items a day
- Storage: 500 MB a day = 913 GB over 5 years, before replicas
- Bandwidth at peak: 2,315 × 2 KB = 4.63 MB/s
- Cache, 80/20 rule (the hottest 20% of a day's reads): 9.90 GB
Approximate AWS on-demand prices for us-east-1, read once in October 2026, before free tiers. They may be out of date; check the AWS pricing pages before you budget.
The five formulas
| What | Formula |
|---|---|
| Average requests/s | daily users × requests per user ÷ 86,400 |
| Peak requests/s | average × peak factor (2-3 is typical) |
| Storage | writes per day × bytes per write × 365 × years, then × replicas |
| Bandwidth | peak requests/s × response size |
| Cache size | hot share of daily reads (often 20%) × item size |
Numbers worth remembering
- A day has 86,400 seconds, about 105. So 1 million requests a day is about 12 per second, and 1 billion is about 12,000.
- A month has about 2.6 million seconds (730 hours).
- 1 KB × 1 million = 1 GB. 1 KB × 1 billion = 1 TB.
- Bits and bytes: network links are quoted in bits. 1 Gbps is 125 MB/s.
- Reads dominate: many consumer products read 10-100× more than they write.
Latency numbers
These come from the classic list by Jeff Dean and Peter Norvig, as collected inthis widely shared gist. They date from around 2012, so treat them as orders of magnitude: hardware is faster now, but the ratios still hold.
| Operation | Time |
|---|---|
| L1 cache reference | 0.5 ns |
| Main memory reference | 100 ns |
| Compress 1 KB with Zippy | 3 µs |
| Read 1 MB sequentially from memory | 250 µs |
| Read 4 KB randomly from SSD | 150 µs |
| Round trip within the same datacenter | 500 µs |
| Read 1 MB sequentially from SSD | 1 ms |
| Disk seek | 10 ms |
| Read 1 MB sequentially from disk | 20 ms |
| Send a packet California → Netherlands → California | 150 ms |
The lesson: memory is about 1,000× faster than a datacenter round trip, which is far faster than a disk seek, and crossing an ocean costs 150 ms no matter how fast your code is. That's why caches sit in memory and CDNs sit near users.
Worked example: a URL shortener
Assume 10 million daily users, 10 redirects each, a 2× peak, 1% of requests creating links, 500 bytes per stored link, and 5 years of data (the calculator's defaults):
- 100 million requests a day ≈ 1,160/s average ≈ 2,300/s at peak.
- 1 million new links a day × 500 bytes = 500 MB a day ≈ 900 GB over 5 years, before replicas. It fits on one database.
- Cache for the hottest 20% of a day's reads: about 10 GB, one memory-optimized cache node.
Each number decides something: one database primary is enough for the writes, a cache is essential for the reads, and the API tier needs only a handful of servers. Now build it and load-test it.
Common mistakes
- Using the average, not the peak. Systems fail in the busiest hour.
- Forgetting replication. Three copies of 1 TB is 3 TB.
- Mixing bits and bytes in bandwidth maths: an 8× error.
- False precision. "2,314.8 requests per second" is no more useful than "about 2,000". Round, and say your assumptions.
Next: turn requests per second into servers with how many users one server can handle, or into a database with database sizing.
Frequently asked questions
How do you calculate requests per second from daily active users?
Multiply daily active users by the requests each user makes per day, divide by 86,400 seconds, then multiply by a peak factor (usually 2 to 3) for the busiest hour. 10 million users making 10 requests a day is 100 million requests a day, about 1,160 per second on average and 2,300 to 3,500 at peak.
How precise do estimates need to be in a system design interview?
Within a factor of two or so. The point is to decide what the design needs: whether one database is enough, whether you need a cache, whether data fits on one machine. Round aggressively and say your assumptions out loud.
What latency numbers should I remember?
The orders of magnitude from the classic list by Jeff Dean and Peter Norvig (circa 2012): a main memory reference is about 100 nanoseconds, a round trip within a datacenter about 0.5 milliseconds, a disk seek about 10 milliseconds, and a packet from California to the Netherlands and back about 150 milliseconds.