System design · interactive
Back-of-envelope estimation
Before designing a photo-sharing app, rough numbers tell you what's hard. Is it reads or writes? Storage or bandwidth? Change the assumptions and see which number explodes first.
| Uploads per day 10.0M users × 2 | 20.0M |
| Write QPS (average) uploads ÷ 86,400 s | 231 |
| Read QPS (average) writes × 50 views | 11.6k |
| Read QPS (peak, ×3) traffic isn't flat | 34.7k |
| New storage per day × 2 MB × 3 copies | 120.0 TB |
| Storage per year × 365 | 43.8 PB |
| Peak egress peak reads × size | 556 Gbps |
| App servers for reads ~2,000 req/s each | 18 |
Reads outnumber writes 50:1, so this is a read-heavy system: cache and CDN everything. Storage grows by 43.8 PB a year, which means object storage with tiering, not a database.
1 Users, actions per user, object sizes, read/write ratio. Round aggressively: the order of magnitude is what matters.
A day ≈ 100,000 seconds.
2 3 4
In production
Tools and technologies
Every system design starts with rough numbers.
Not tied to one language — use these names when you search docs or design a system.