Scenario Modeling

Back to Performance Tuning and Capacity Planning · Trend-Based Projections · Per-Resource Runway · Lead-Time Awareness · Service Offerings

Forecasts adjusted for known upcoming events — a marketing push, a new client, a seasonal spike — not just steady-state growth. The word doing the work is known. These are not predictions about the future; they are facts already recorded somewhere in the organisation and absent from the capacity plan.

1. The Information Already Exists Elsewhere

A trend projection assumes the recent past continues, and the people who know it will not are usually in a different meeting. The illustration above is what that gap looks like: steady growth never reaches capacity, and the same forecast with three already-scheduled events reaches it inside the year.

Where to find them, in roughly descending order of how often they are missed:

• Marketing — campaign dates and expected reach, which exist as a plan months ahead.
• Sales — signed clients not yet onboarded, with their expected volume in the contract.
• Product — launches, and features that change usage shape rather than volume.
• Finance — the growth the budget assumes, which is a forecast somebody already committed to.
• Your own roadmap — a migration, a refresh, a decommissioning. Capacity being released counts as much as capacity being consumed.

None of this requires forecasting skill. It requires asking, and then writing the answers into the model.

2. Model the Peak, Not the Total

A campaign that brings a hundred thousand extra visits over a fortnight sounds like a modest daily increase. It will not arrive that way: the traffic concentrates in the hours after the email goes out, and the first hour is a multiple of everything else.

• Ask for the shape, not just the number. When it starts, how it is delivered, and what happened last time.
• Use last time's shape if there is one. The ratio of peak hour to daily total is remarkably stable per channel, and far more reliable than an estimate.
• Push notifications and email concentrate hardest, because everyone receives them at once.
• Check what the peak does to each resource separately — a spike may be comfortably within CPU and well past the connection limit.

3. A New Client Is Not an Average Client

Capacity for onboarding is routinely estimated by dividing current usage by current customers. That number is an average, and new clients are rarely average.

• Size matters more than count. One customer twenty times the median moves everything; twenty median ones are a rounding error.
• The import is the spike. Migrating a client's history is often the largest single load that account will ever generate, and it lands before any revenue does.
• Usage patterns differ. A client in another timezone flattens your daily curve; one in your own sharpens it.
• Per-client storage rarely shrinks, so onboarding is a permanent step in the storage forecast rather than a temporary one.

4. Three Scenarios, Not One Number

Model a base case from the trend, an expected case with the events everyone agrees are happening, and a high case where the uncertain ones land as well. Each produces a date.

• Plan against the expected case and know what the high case costs.
• Where the two differ by less than the lead time, the distinction is academic — act on the earlier one. See lead-time awareness.
• Label the assumptions, not just the lines. A scenario whose contents are written down can be updated when one event slips; one that is only a number cannot.
• Resist adding more than three. Beyond that nobody reads them and the exercise becomes its own output.

5. Scenarios Worth Modelling That Nobody Requests

• Losing one instance at the busiest moment. Capacity that works at peak with everything healthy is not capacity.
• The retry storm. A partial failure makes clients retry, and the load after an incident is higher than the load that caused it.
• A dependency becoming slow. Not failing — slow. Connections are held longer, pools drain, and the resource that runs out is not the obvious one.
• The campaign that works far better than expected, which is a real outcome and is never the plan.

6. Keep It Alive

A scenario model is wrong the moment a date moves, and dates move constantly. What keeps it useful is that it is cheap to update: the events are a short list, each with a date and a size, and revisiting it is a ten-minute job on the review cadence rather than a rebuild.

Record what actually happened against each event once it passes. A campaign that produced half the predicted load, twice, is a calibration for the next one — see forecast versus actual.

How We Approach It

1. Collect the known events from marketing, sales, product, finance and your own roadmap, each with a date and an expected size.
2. Convert each into peak load, using the shape from the last comparable event rather than an average.
3. Apply them per resource, since an event that is comfortable for one can exhaust another.
4. Produce base, expected and high cases, each with its assumptions listed.
5. Add the scenarios nobody asked for: instance loss at peak, retry storms, a slow dependency.
6. Record outcomes against predictions so the next model is calibrated.

What You Get

• The known events gathered into one list with dates and sizes, which on a first pass is usually the first time they have been in the same place.
• Each converted into peak load per resource, not an average daily increase.
• Three dated scenarios with their assumptions written beside them.
• The unrequested scenarios modelled, which is where capacity plans usually turn out to be optimistic.
• A record of outcome against prediction, so the model improves instead of being rebuilt.

The question that starts this work, and that is almost never asked of the people who can answer it: what is happening in the next six months that will change how much of this we use?