Capacity planning for a peak you only get once a year

Capacity planning built only on averages can hide the event that defines the year. A university's network is tested by enrolment week, a Gulf retailer's operation by Ramadan and White Friday, and a finance team's systems by year-end close. Provisioning only for the mean leaves the peak exposed; provisioning for the peak year-round can leave expensive capacity idle.

The discipline is to plan the peak as an event, not a load figure. That means knowing not just how much traffic arrives, but its shape: enrolment traffic is thousands of short authenticated sessions hitting identity systems simultaneously; retail peaks are payment-path-heavy; close periods hammer reporting queries. The bottleneck is rarely raw bandwidth — it is the one shared service every request touches.

Cloud services make it possible to add capacity for a defined peak rather than hold it all year. That elasticity still needs proof. Rehearse the expected traffic shape before the event with explicit go/no-go criteria, then investigate constraints such as connection pools, licence ceilings, identity dependencies and downstream systems that do not scale with the front end.

The AI layer helps at the edges of a peak, too — voice agents absorb the enquiry surge that accompanies every enrolment week and product launch, queueing the routine questions away from staff who are needed for exceptions. But the principle is the same as for every other component: if it has not been rehearsed at peak shape, it is not capacity. It is a forecast.