System designCore3 min
Back-of-the-envelope estimation
Turn 50 million users into requests per second, storage and bandwidth in two minutes, so you know which part of the design will break first.
1 · Why bother
Order of magnitude decides the design
A system taking 50 writes a second fits on one database. One taking 50,000 needs partitioning, and one taking 5 million needs a different design. You don't need the exact number; you need the power of ten, fast, with your assumptions written down.
2 · Numbers to keep
A handful of conversions do most of the work
| Fact | Round it to | Use |
|---|---|---|
| Seconds in a day | 86,400 ≈ 10⁵ | Per day → per second: divide by 10⁵ |
| 1 million per day | ≈ 12 per second | 1 billion per day ≈ 12,000/s |
| Peak vs average | 2–3× (10× for launches) | Size for the peak, not the average |
| KB, MB, GB, TB | 10³, 10⁶, 10⁹, 10¹² | Close enough to 2¹⁰, 2²⁰, 2³⁰, 2⁴⁰ |
| Days in a year | ≈ 400 for rough maths | Storage per year: per day × 400 |
| Memory vs SSD vs network | 100 ns · 100 µs · 0.5 ms in a datacenter | Which layer can meet a latency target |
3 · Worked example
A messaging app, end to end
- State the assumptions.
50 million daily users, 40 messages sent each, about 200 bytes per message with metadata.
- Writes per second.
50M × 40 = 2 billion messages a day. 2 × 10⁹ / 10⁵ = 20,000/s on average, so plan for about 60,000/s at peak.
- Reads per second.
Each message is read by about 1.5 people on average (groups): ≈ 30,000/s, 90,000/s at peak.
- Storage.
2 × 10⁹ × 200 B = 400 GB a day. × 400 days ≈ 160 TB a year, and × 3 replicas ≈ 480 TB.
- Bandwidth.
60,000/s × 200 B = 12 MB/s of writes at peak. Small: the hard part here is write rate and storage, not the network.
- Conclude.
60,000 writes/s and half a petabyte a year rule out a single database: partition the messages, and plan for cheap cold storage of old ones.
Peak rates against what one machine can take: the comparison that matters. The last bar is a rule of thumb for simple writes, not a benchmark.
4 · Good habits
How to keep estimates honest
- Say every assumption out loud and write it down; someone will want to change one.
- Round hard: 86,400 is 10⁵, 2.6 million seconds in a month is fine as 2.5.
- Keep units on every number. Most estimation mistakes are a lost factor of 8 (bits and bytes) or 1,000.
- Stop at the decision. Once you know it's thousands, not millions, move on.
5 · In a real system
From new links a month to requests a second
URL Shortener System Design
The URL shortener's estimate drives its load
The design starts from new links per month and reads per write: 100 million links a month is about 40 writes a second, and 100 reads per write makes it about 4,000 reads a second. Change the assumptions in the simulator and the traffic follows.
Check yourself
3 questions
Takeaways
Remember this
- Aim for the right power of ten, with the assumptions written down.
- Per day ÷ 10⁵ ≈ per second; 1 million a day ≈ 12 a second.
- Size for the peak (2–3× the average), and count replicas in storage.
- Stop once the numbers have made the decision for you.