Do a back-of-envelope capacity estimate for a messaging feature: writes per second, fan-out, storage and bandwidth, and what you conclude from them.

26.7.1 · L5 · Interview

Predict first

With these assumptions, what are the peak writes per second and the yearly storage with three replicas?

let dau = 20_000_000, sentPerUser = 40, recipients = 3, bytes = 300, peakFactor = 4, day = 86_400
let sends = dau * sentPerUser                                  // per day
let avgWrite = sends / day, peakWrite = avgWrite * peakFactor
let deliveries = sends * recipients
let peakDeliver = deliveries / day * peakFactor
print("messages/day:", sends, "avg writes/s:", avgWrite, "peak writes/s:", peakWrite)
print("deliveries/day:", deliveries, "peak deliveries/s:", peakDeliver)
let perDayGB = Double(sends) * Double(bytes) / 1e9
print("storage/day GB:", perDayGB, "per year TB:", perDayGB * 365 / 1000, "x3 replicas TB:", perDayGB * 365 * 3 / 1000)
let mbps = Double(peakDeliver * bytes * 8) / 1e6
print("peak egress Mbit/s:", mbps, "(headers and TLS excluded)")
// one phone: how much does a user receive?
let recvPerUser = sentPerUser * recipients                     // average, since every send has 3 recipients
print("per user per day: sends", sentPerUser, "receives", recvPerUser, "-> KB", recvPerUser * bytes / 1000)
  • 37,036 writes/s at peak and 262.8 TB a year with three replicas
  • 9,259 writes/s at peak and 87.6 TB with replicas
  • 111,108 writes/s and 240 TB

Mental model. Pacing a road trip: distance, speed and fuel stops. The answer is rough, but you find out before leaving that you need two fill-ups, not twenty.

State assumptions first, then compute. Take 20 million daily active users sending 40 messages a day, each delivered to 3 recipients, 300 bytes per message, and a peak of 4 times the average. Messages per day are 800 million; dividing by 86,400 seconds gives about 9,259 writes per second on average and 37,036 at peak. Fan-out multiplies deliveries to 2.4 billion a day and about 111,108 per second at peak. Storage is 800 million × 300 bytes = 240 GB a day, 87.6 TB a year, and 262.8 TB with three replicas. Peak egress for payloads alone is about 267 Mbit/s (headers and TLS excluded). On the phone, each user receives about 120 messages a day, roughly 36 KB: trivial for data, which tells you the client’s cost is in wake-ups and rendering, not bytes.

What do the numbers say? 37 thousand writes a second is a sharded database, not one machine; the 12× jump from sends to peak deliveries says the read and fan-out path is the cost centre, so you would store each message once and fan out references; 240 GB a day says retention and cold storage are a product decision. Show the method more than the digits: use round numbers (a day is about 10^5 seconds), keep units on every line, separate average from peak, and check each result against an anchor (a single database node handles thousands of writes a second, not hundreds of thousands). For mobile also estimate per-device budgets: bytes a day, radio wake-ups, local storage for media, and push volume. The figures here come from the assumptions in the question, run in a short program; they are not measurements of any real service, and you should say so.

Average rate times a peak factor, and bytes per day times days times replicas.

Common traps

  • Using the average as the capacity. Systems fail at the peak; apply a peak factor and state it.
  • Forgetting fan-out. One send is many deliveries, and that multiplication is usually the dominant term.

They might follow up with

  • How accurate should it be? Within a factor of two or three; the goal is to pick an architecture, not size the invoice.
  • What changes at 10× scale? Name the first thing that breaks (usually the write path or hot partitions) and what you would shard or cache.

Related questions

  • 26.2.2 How do you set payload budgets and reduce bytes: field selection, deltas, compression, image sizes, and what…
  • 26.1.2 Design a messaging client: transport, ordering, delivery states, offline sending, media, notifications and…
  • 26.4.2 How do you estimate honestly, cut scope, and sequence a large migration: ranges, the critical path, vertical…
  • 13.7.1 How would you design multi-device sync: identity, change tracking, conflict resolution, deletions and…

What happens when ten thousand clients retry after an outage: compare… →