An estimate isn't about being exact. It's about knowing whether you need one server or a thousand, a gigabyte or a petabyte. Being within a factor of two or three is plenty.
Requests per second
The one number to remember: a day has 86,400 seconds, call it 100,000 (10⁵).
Say an app has 10 million daily users, each making about 10 requests a day:
- Requests per day: 10M × 10 = 100M (10⁸)
- Average per second: 10⁸ ÷ 10⁵ = 1,000 (the exact figure, using 86,400, is about 1,160: close enough)
- Peak is higher, because people don't use apps evenly. A common rule of thumb is 2–3× the average: here, about 3,000 requests per second.
Design for the peak, not the average. A system sized for the average falls over every evening.
Storage
Now say 10% of those users upload one photo a day, at about 2 MB each:
- Photos per day: 1M
- Bytes per day: 1M × 2 MB = 2 TB a day
- Per year: 2 TB × 365 ≈ 730 TB. Most systems keep 3 copies for safety, so about 2 PB of disk
That one line tells you that photos can't live on one machine, and that storage cost matters.
Keep it quick
- Round aggressively. 86,400 → 100,000. 365 → 400 if it helps.
- Use powers of ten. Thousand = 10³, million = 10⁶, billion = 10⁹. KB, MB, GB, TB, PB each step ×1,000.
- Say your assumptions out loud. "Assume 10 requests per user per day." If someone disagrees, you change one number, not the method.
Key idea: daily requests ÷ 100,000 ≈ requests per second. Multiply by 2–3 for the peak. Storage = items per day × size × days. Round hard and state your assumptions.