Fundamentals
Napkin constants
The handful of numbers worth memorizing so you can estimate scale in your head, from seconds per day to what one server can handle.
Estimation is fast only when you don't stop to look things up. A few constants cover most of it: how many seconds are in a day, the powers of two, the size of common objects, and what one server can handle. Learn them once, and the rest is multiplication.
Time and traffic
- A day has 86,400 seconds. Round it to 10^5 for mental math. That overestimates the seconds by about 16%, so your per-second rates come out slightly low. That's fine at this precision, but remember the bias.
- 1 million requests a day is about 12 requests per second (10^6 ÷ 86,400 ≈ 11.6).
- 1 billion requests a day is about 12,000 per second.
- A month is about 2.6 million seconds. A year is about 31.5 million, roughly π × 10^7, which makes a handy mnemonic.
- Peak traffic is usually 2 to 3 times the daily average for consumer products. Spiky products, such as ticket drops, sports and push-notification traffic, can hit 10 times or more for minutes. Size for the peak.
Here is the arithmetic for 200 million requests a day:
200,000,000 requests/day ÷ 86,400 s ≈ 2,300 requests/s average
2,300 × 3 (peak factor) ≈ 7,000 requests/s peakPowers of two and data sizes
| Power | Exact value | Approx. | Unit |
|---|---|---|---|
| 2^10 | 1,024 | 1 thousand | 1 KB |
| 2^20 | 1,048,576 | 1 million | 1 MB |
| 2^30 | 1,073,741,824 | 1 billion | 1 GB |
| 2^40 | ~1.1 × 10^12 | 1 trillion | 1 TB |
| 2^50 | ~1.1 × 10^15 | 1 quadrillion | 1 PB |
Useful anchors for object sizes:
| Thing | Rough size |
|---|---|
| A UUID or 64-bit ID pair | 16 bytes |
| A 64-bit integer or a timestamp | 8 bytes |
| A short text post with metadata | 300 B to 1 KB |
| A typical JSON API response | 1 to 20 KB |
| A compressed phone photo | 1 to 3 MB original; 100 to 300 KB as a feed-sized variant |
| One minute of 1080p video | roughly 50 to 100 MB, depending on bitrate |
Single-node capacity
These numbers let you count servers. They vary by an order of magnitude, so treat them as starting points.
| Component | Rough capacity on one modern node |
|---|---|
| Web or app server, simple JSON endpoint | 1,000 to 10,000 RPS per core for trivial handlers; often 500 to 5,000 RPS per box for real business logic |
| Postgres or MySQL | About 10,000 simple indexed writes/s; tens of thousands of point reads/s |
| Redis or Memcached | About 100,000 ops/s per instance (Redis is single-threaded) |
| Kafka broker | About 100 MB/s of sustained writes is comfortable; much more on good disks |
| Persistent connections (WebSockets) | 100,000 to 1,000,000+ per tuned server; memory per connection is the limit |
| A single NIC | 10 to 100 Gbps (about 1.25 to 12.5 GB/s) |
Benchmarks show much higher numbers for tiny operations on huge machines. In a design doc, conservative numbers with headroom are easier to defend.
Common mistakes
- Mixing up 1,000 and 1,024. Either is fine for estimates. The gap grows when you multiply by a billion.
- Quoting a per-core rate as a per-box rate. A box has many cores, but real handlers do far less work than trivial ones.
Check yourself
1. About how many requests per second is 5 million requests a day? About 58 per second (5,000,000 ÷ 86,400), or roughly 50 to 60 with the shortcut.
2. Why state conservative numbers in a design doc? Benchmarks for tiny operations on huge machines run far higher. Conservative figures with headroom hold up when someone asks why you chose them.
Key takeaways
- 86,400 seconds is about 10^5. One million requests a day is about 12 per second.
- Most consumer products peak at 2 to 3 times their daily average. Size for the peak.
- For estimates, 1 KB ≈ 1,000 bytes is fine. Keep the units straight.
- Treat the single-node numbers as conservative starting points.
Further learning
Next, see how far apart the layers of a computer are in latency numbers.
The Napkin Math repository by Simon Eskildsen pairs estimates with small benchmarks, which keeps your constants current.
Related
Latency numbers every engineer should know
A reference table of how long memory, disk and network operations take, and the ratios that decide where a design can afford to wait.
The estimation chain
The five steps that turn users and behavior into queries per second, storage, bandwidth and server count, with the multipliers you should say out loud.
Back-of-the-envelope estimates
Turn users and features into QPS, storage and bandwidth numbers in two minutes, and use them to decide what the design actually needs.