System designCore7 min
Estimation, capacity & cost
Turn 10 million users into requests per second, terabytes, machines and a monthly bill in a few lines of arithmetic, and find out which part of the design matters most before you draw it.
1 · Why bother
An estimate picks the design; it does not predict the future
A system taking 50 writes a second fits on one database. One taking 50,000 needs its data split across many machines. One taking 5 million needs a different kind of design altogether. Before you draw anything, you need to know which of those you are building.
Writes per second | What it means for the design |
|---|---|
50 | One database handles it |
50,000 | The data has to be split across many machines |
5,000,000 | A different kind of design altogether |
You need the right power of ten, not the right number.
So estimates are rough on purpose. Round hard, write every assumption down, and stop as soon as the numbers have made the decision. Being off by 30% changes nothing; being off by 100 times changes everything.
2 · The toolkit
A handful of numbers do most of the work
Fact | Round it to | Use it for |
|---|---|---|
Seconds in a day | 86,400, call it 10⁵ | Per day → per second: divide by 10⁵ |
Seconds in a month | About 2.6 million | Per month → per second |
1 million a day | About 12 a second | A quick sanity check on any daily figure |
Busiest hour vs average | Often 2–3×, far more at a launch or a sale | Size for the peak, never the average |
KB, MB, GB, TB, PB | 10³, 10⁶, 10⁹, 10¹², 10¹⁵ bytes | Storage and bandwidth |
Two unit traps cause most estimating mistakes:
- Bytes and bits. Storage is counted in bytes, network speed in bits a second. 1 GB/s of data is 8 Gbit/s on the wire.
- Thousands and 1,024s. A kilobyte is 1,000 bytes; a kibibyte (KiB) is 1,024. The gap is 2.4% at the kilobyte and 10% at the terabyte. Fine for an estimate, as long as you do not mix them in one sum.
3 · Traffic
From users to requests per second
Take a photo-sharing app. Everything starts from a few assumptions, stated out loud so anyone can challenge them:
- 10 million people use it every day.
- One in five posts a photo each day: 2 million uploads a day.
- Each person looks at about 50 photos a day: 500 million views a day.
- The busiest hour runs at about 3 times the daily average.
What | Per day | Average per second | At the peak |
|---|---|---|---|
Uploads | 2 million | 2,000,000 ÷ 86,400 ≈ 23 | About 70 |
Views | 500 million | 500,000,000 ÷ 86,400 ≈ 5,800 | About 17,000 |
About 250 views for every upload. Whatever else the design does, it must make looking at photos cheap.
4 · Storage and bandwidth
Storage grows every day; bandwidth is spent every day
Two more assumptions: the app keeps each original photo at about 2 MB, and shows people a smaller copy of about 200 KB. Now the bytes:
What | The sum | Result |
|---|---|---|
New photos stored a day | 2 million × 2 MB | 4 TB a day |
Stored after a year | 4 TB × 365 | About 1.5 PB |
Sent to viewers a day | 500 million × 200 KB | 100 TB a day |
Sent to viewers a month | 100 TB × 30 | 3 PB a month |
4 TB a day is about 120 TB a month, so the pile climbs in a straight line and never comes down: about 1.5 PB after a year. The storage bill climbs with it, by about $2,400 every month (120,000 GB × $0.02).
Storage piles up: every photo ever posted stays, so the total only grows. Bandwidth does not pile up, but it is spent again every single day. As a rate, 100 TB a day is about 1.2 GB a second, or roughly 9 Gbit/s on average and nearly 30 Gbit/s at the peak.
5 · Capacity
How many machines, with room to spare
The photos themselves are served straight from storage. The app servers handle everything else: sign-in, the feed, the list of photos to show. So their load is the 17,000 views a second at the peak.
- Measure one machine.
How much one server can take is an assumption until a load test proves it. Say one handles 1,000 requests a second.
- Divide.
17,000 ÷ 1,000 = 17 servers, each 100% busy at the peak.
- Leave room.
A server near 100% busy answers many times slower than one at 60% (Throughput, utilization & queueing shows why). Plan for about 60%: 17 ÷ 0.6 ≈ 29.
- Survive a failure.
Round up to 30. If one dies at the peak, the other 29 each run at about 59%: still comfortable.
The buffer is not waste. It is what keeps the app fast on its busiest evening and standing when a machine fails.
6 · The bill
Add up the monthly bill, then look at the biggest line
Now turn it into money. Round list prices from the large cloud providers, US regions, September 2026:
- A server with 2 CPUs and 8 GB of memory: about $0.10 an hour, roughly $70 a month.
- Storing a file in object storage: about $0.02 per GB each month.
- Sending data out to the internet: $0.09 per GB for the first 10 TB a month, falling to about $0.05 at large volumes.
Line | The sum | Per month |
|---|---|---|
Servers | 30 × $70 | About $2,100 |
Storage, after a year | 1.5 million GB × $0.02 | About $30,000 |
Data sent to viewers | 3 million GB × about $0.05 | About $150,000 |
The servers everyone debates are about 1% of the bill. Sending photos to people is more than 80% of it.
That changes where the effort goes:
- Make the photos smaller. Halve the size of what you send and you halve the biggest line.
- Send them from closer. A content delivery network keeps copies near viewers; at this volume it is usually cheaper per GB, and faster too.
- Move old photos to colder storage. Photos nobody has opened in a year can live on cheaper, slower storage.
Prices change, and large customers negotiate. The lesson does not change: find the line that dominates before you optimize anything.
Check yourself
5 questions
Takeaways
Remember this
- Aim for the right power of ten, with every assumption written down.
- Per day ÷ 10⁵ ≈ per second; size for the peak, not the average.
- Storage grows forever; bandwidth is spent every day. Watch bytes versus bits.
- Machines = peak ÷ what one machine can take, planned at about 60% busy, with a spare.
- Add up the bill and find the biggest line before optimizing anything.