You expect 10x traffic on a known date six weeks away. Walk through the preparation.

What is being tested

Whether you exploit the fact that the date is known, and whether your plan is organisational as well as technical.

Why a known date changes the strategy

For unpredictable load, elasticity is the answer. For a known date, pre-provisioning is rational. Autoscaling takes minutes and a 10x step change does not wait; and several resources — reserved capacity, database scaling, quota increases, third-party limits — have lead times measured in weeks.

That is exactly why six weeks is the right amount of notice and why the plan starts with the things that cannot be done quickly.

Weeks 1–2: know the numbers and secure what has lead time

• Model capacity from measured unit costs — CPU-seconds, database queries and bytes per request, per endpoint. Multiply by 10 and add headroom for failure-domain loss.
• Load test at 10x and beyond, against production-scale data, with a realistic request mix and a cold cache. Find the knee, not just whether the target passes.
• Secure reserved capacity and quota increases, which is the item most likely to be blocked by someone else's process.
• Confirm third-party limits. Payment processors, delivery partners, email providers, SMS gateways all have limits, and their limit is your limit. This is the most commonly missed item and the one you cannot fix on the day.

Weeks 3–4: fix what the tests found and prepare degradation

• Address the bottlenecks the load test revealed, re-testing after each.
• Agree degradation modes with product: what gets disabled, in what order, and who decides. Recommendations, personalisation, non-essential notifications and reporting are usual candidates.
• Review every timeout, retry and circuit breaker configuration. Retry storms are the standard way a peak event becomes an outage.
• Test load shedding and admission control, with agreed thresholds. Untested shedding does not work when triggered.
• Rehearse the runbook.

Week 5: freeze and warm

• Change freeze, with a documented exception path for genuine fixes. The cost of a bad deployment on the highest-revenue day exceeds the value of anything shipped that week — this is a rational trade, not institutional caution.
• Verify rollback works, for both code and configuration.
• Brief support and prepare customer communications for each degraded scenario.

The day: ahead of the ramp and during

• Scale up before traffic arrives, not in response to it.
• Warm caches and pre-render what can be pre-rendered. A cold cache at the ramp means the origin takes the full load in the first minute.
• Extra staffing with clear roles, including a business decision-maker on call — someone authorised to say "disable that feature". Without a named person, a business call waits 40 minutes while someone is found.
• Watch business metrics, not just technical ones.

The pattern worth knowing

If 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 an estimate, and keep the core system inside its capacity. This converts an outage into a queue, which customers understand and which preserves the transaction.

Afterwards

Review, and record the actual figures — real peak, real unit costs, what broke — so next year's model starts from measurement rather than from last year's guess.