Back-of-the-envelope estimation for system design

Before choosing a database or counting servers, estimate the size of the problem. Rough numbers are enough. They tell you whether one machine is fine or you need a distributed design.

Numbers worth remembering

• 1 day = 86,400 seconds, so call it about 100,000 (10^5) seconds.
• 1 million requests per day is about 12 per second.
• 1 KB, 1 MB, 1 GB, 1 TB: each is about 1,000 times the last.
• Rough latencies: memory read ~100 ns, SSD read ~100 microseconds, round trip inside a data centre ~0.5 ms, across continents ~150 ms.
• A single decent server handles thousands of simple requests per second.

Worked example: a photo-sharing app

Assume: 10 million daily active users, each views 50 photos and uploads 0.2 photos per day. An average photo is 2 MB.

Reads per second: 10M x 50 = 500M per day. Divide by 100,000 = about 5,000 reads/s. Peak is often 2 to 3 times the average, so plan for roughly 15,000/s.

Writes per second: 10M x 0.2 = 2M uploads per day, about 20 uploads/s.

Storage per day: 2M x 2 MB = 4 TB per day, about 1.5 PB per year. This tells you straight away that you need object storage and a CDN, not a database for images.

Bandwidth out: 5,000 views/s x 2 MB = 10 GB/s. That is a CDN job, not a single origin.

Habits

1. State assumptions out loud. They matter more than the answer.
2. Round hard. 86,400 becomes 100,000.
3. Separate reads and writes. The ratio drives the design.
4. Plan for peak, not the average.
5. Check units (bits vs bytes, per day vs per second).

What to do with the result

Compare it with what one machine can do. 20 writes/s is trivial. 15,000 reads/s of tiny data fits a cache. 1.5 PB per year does not fit one server.

Takeaway: a two-minute estimate shapes the whole design, so do it first and write down your assumptions.

---

Part 15 of 15 in the System Design series. Previous: Idempotency: making retries safe.