This trace follows the actual state transitions behind the companion Start System Design With a Workload Model. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Describe arrivals and payloads
A workload model describes request rates, payload sizes, read/write mix, burstiness, and latency goals. Capacity estimates are useful when they expose assumptions and identify dominant resource costs; a single total-user count rarely predicts the load a system must handle.
Step 2: Estimate average and peak rate
If one million users each make two requests per day, the average is far below the peak if activity clusters around a short window. Estimate average and peak requests per second, then multiply by bytes, storage retention, and downstream calls. State whether retries and background jobs are included.
Step 3: Include fan-out and retries
Convert users into operation rates and sizes, including bursts and downstream calls; distinguish the average load from the peak the system must serve.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Compare demand with capacity
Back-of-the-envelope numbers are ranges, not promises. Cache hit rate, hot keys, payload distribution, and fan-out can change capacity sharply. Averages hide tail latency and bursts, so design headroom and measure the real workload before purchasing or sharding capacity.
Step 5: Add headroom and observe
Estimate storage for event records given an arrival rate, average encoded size, and retention period. Then name two additional factors needed before sizing the database.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.