Peak Event Readiness

Definition

A peak event is a known date with an expected multiple of normal traffic: a retail sale, a product launch, a ticket release, an election night, a major sporting fixture. Its defining property is that the date is known in advance, which changes the strategy entirely.

Why a known date changes the approach

For unpredictable load, elasticity is the answer. For a known date, pre-provisioning is rational: capacity is reserved in advance, warmed, and tested. Autoscaling still matters as a safety net, but relying on it for a 10x step change is a mistake — scaling takes minutes and some resources (database capacity, reserved instances, third-party quotas) have lead times measured in weeks.

This is why retail organisations plan the year around a small number of dates, and why change freezes around them are a rational trade rather than institutional caution: the cost of a bad deployment on the highest-revenue day of the year exceeds the value of anything shipped that week.

The preparation

Weeks before

• Load test at the expected peak and beyond, against production-like data, with realistic mix.
• Model capacity from measured unit costs; secure quota increases and reserved capacity.
• Confirm third-party providers can handle your volume — payment processors, delivery partners, email providers all have limits, and their limit is your limit.
• Identify and rehearse degradation modes; agree with product what gets disabled and in what order.
• Review every timeout, retry and circuit breaker configuration.

Days before

• Change freeze, with a documented exception path for genuine fixes.
• Warm caches, pre-render what can be pre-rendered, scale up ahead of the ramp.
• Verify rollback works, for both code and configuration.
• Brief support and prepare customer communications for the degraded scenarios.

During

• Extra staffing with clear roles, and a decision-maker available for business calls such as disabling a feature.
• Dashboards focused on business metrics, not just technical ones.
• Load shedding and admission control ready and tested, with agreed thresholds.

After

• Review, and record the actual figures for next year's model.

The queue pattern worth knowing

For events where demand structurally exceeds capacity — a limited-inventory sale — a virtual waiting room is the honest answer. Admit users at a rate the system can serve, show a position and estimate, and keep the core system inside its capacity. This converts an outage into a queue, which customers understand and which preserves the transaction.

Failure scenarios

• Autoscaling relied on for a step change, arriving minutes too late.
• A third party's limit discovered at peak.
• A cold cache at the ramp, so the origin takes the full load in the first minute.
• Load shedding untested, so it does not work when finally triggered.
• No agreed decision-maker, so a business call waits 40 minutes for someone to be found.

Interview question

"You expect 10x traffic on a known date six weeks away. Walk me through your preparation plan."