Reference

Workload estimation notes

A sequence for keeping a rough estimate visible, checkable, and tied to a design question.

Estimate in this order

  1. Clarify the workload: users, user journeys, request types, geography, daily volume, growth, and known traffic bursts.
  2. Separate reads and writes. Make clear whether one user action causes one request or several.
  3. Convert daily totals to average rates: requests per day ÷ 86,400 seconds per day.
  4. Estimate a stated peak: average rate × scenario peak factor. Explain the interval and why that factor is plausible for this exercise.
  5. Estimate retained data: records per day × bytes per record × retention days. State whether the result is raw logical data or includes indexes, replicas, backups, and headroom.
  6. Estimate transfer: requests per second × average payload bytes. Keep inbound and outbound directions separate; multiply bytes per second by 8 to get bits per second.
  7. Check whether a reasonable range changes a decision. If it does, call out the sensitivity rather than presenting a false-precision point estimate.
Keep the labels Write units beside the numbers. “170” is not useful; “about 170 read requests/second during a major on-sale” can be checked and challenged.

The arithmetic is only a model of the assumptions you wrote down. Real production choices need observed workload data, product targets, and service measurements.

Units

For related terms, see the glossary. For the learning exercise and its fictional inputs, see Workload estimation.