LESSON 3.3
Back-of-the-envelope math
Turn users and actions into requests per second, storage and bandwidth with a few simple formulas and powers of ten.
5 min read
Estimation is not about being right to the decimal. It is about learning which parts of the system are big: is this a 100-requests-a-second system or a 100,000? Is the data gigabytes or petabytes? Those answers decide the architecture.
The few facts you need
- Seconds in a day
- 86,400 ≈ 10^5
- Seconds in a month
- ≈ 2.5 × 10^6
- Seconds in a year
- ≈ 3 × 10^7
- Thousand / million / billion
- 10^3 / 10^6 / 10^9
- KB / MB / GB / TB / PB
- 10^3 / 10^6 / 10^9 / 10^12 / 10^15 bytes
- One character (ASCII)
- 1 byte
- A UUID / a timestamp
- 16 bytes / 8 bytes
- A typical small DB row
- 100 B – 1 KB
- A compressed photo
- ~200 KB – 2 MB
- A minute of HD video
- ~50–100 MB
Rounding 86,400 to 100,000 makes the arithmetic easy, and the 15% error does not change any design decision.
Three formulas
Requests per second
average QPS = daily active users × actions per user per day ÷ 86,400
peak QPS ≈ average QPS × 2–3 (or more for spiky products)Do it separately for reads and writes; they usually differ by 10–100×, and they push the design in different directions.
Storage
storage per year = new items per day × size per item × 365Then multiply by the replication factor (often 3) and remember indexes and metadata add overhead.
Bandwidth
bandwidth = QPS × size per responseThis one matters for media. 10,000 requests a second for a 1 MB image is 10 GB a second, about 80 Gbit/s: far more than one server's network card. That is when you need a CDN.
A quick example
A photo-sharing app: 10 million daily users, each views 50 photos and uploads 0.2 photos a day. Photos average 500 KB.
- Writes: 10M × 0.2 = 2M uploads a day ÷ 10^5 ≈ 20 uploads/s average, maybe 60 at peak. Small.
- Reads: 10M × 50 = 500M views a day ÷ 10^5 ≈ 5,000 views/s average, ~15,000 at peak. Read-heavy, 250:1.
- Storage: 2M × 500 KB = 1 TB a day → ~365 TB a year, ~1 PB with 3× replication. Object storage, not a database.
- Bandwidth: 15,000 × 500 KB ≈ 7.5 GB/s at peak. That needs a CDN.
- Metadata: 2M rows a day × ~500 B ≈ 1 GB a day, ~365 GB a year. One relational database handles this fine for years.
Look at what the estimate told you: uploads are tiny, metadata is small, but bytes and bandwidth are huge. The design writes metadata to a database, stores photos in object storage, and serves them through a CDN. The math made the architecture obvious.
Try it
Video Streaming HLD
An estimate where bandwidth, not request count, dominates the design.