Back-of-envelope estimation

• QPS = requests per period / seconds in the period. A day is ~100K seconds (86,400), a month ~2.5M.
• Storage = records x size per record x retention.
• Read:write ratio drives caching and replication.

100M new URLs / month
writes  = 100M / 2.5M s  = ~40 writes/sec
reads   = 100x writes    = ~4,000 reads/sec
1B objects at ~10 bits/key in a Bloom filter = ~1.25 GB

40 writes/s and 4K reads/s is tiny. One Postgres with a cache could handle it. Interviewers love hearing that a "scale" problem does not need exotic tech.

average: 150M / day  = 150M / 100K s  = ~1,500/s (exact ~1,750, say "about 2K")
peak:    100M in 10 min = 100M / 600 s  = ~170,000/s
peak is ~100x the average

The 100x gap is the design driver. You cannot size for the average, because the burst would crush you; you shape the burst instead (see the notification system mock).

• Use powers of ten. 5 billion messages / 10^5 seconds = 50,000 per second, not 50. Count the zeros before you build on the number.
• Daily active users are not concurrent users. People are spread across time zones. Assume roughly 30-50% connected at the peak, and say it out loud.
• Connections per box. A tuned server holds hundreds of thousands of idle connections (plan ~200K). 200M connections / 200K = ~1,000 gateways.
• Media dominates storage. 5x10^8 images x 2 MB = 10^15 bytes = 1 PB per day, 2,000x the text volume. Never leave media out.
• Fan-out multiplies deliveries. One send to a 500-member group is up to 500 deliveries. Count sends and deliveries separately.
• Plaintext is not the stored size. Add ciphertext overhead, headers and metadata.