Traffic spikes don't take sites down; unprepared origins do. The edge is built for multiples of your peak — your origin is built for Tuesday. Spike preparation is therefore mostly a game of making sure the wave breaks on the CDN and only a trickle reaches the systems that can drown, with a rehearsed plan for the scenario where the trickle grows anyway. This is the checklist, in the order to run it.
Forecast: size the wave
Put numbers on the spike before engineering anything: expected multiple of normal peak (from last year's event, the marketing plan's reach, or comparable launches), its geography, its timing shape (a TV-ad cliff is not a sale-day plateau), and the traffic mix — a flash sale is browse-heavy and cacheable, a ticket drop is transaction-heavy and isn't. From the forecast derive the two numbers the rest of the checklist serves: projected edge bandwidth (mostly a commercial question — check your commit and overage terms) and projected origin request rate, which is spike traffic times your miss-and-pass rate on the affected paths. That second number is the one that kills sites, and every following step exists to shrink it or survive it.
Maximize offload before the day
Every percentage point of hit ratio is a percentage point of the spike your origin never meets, so the weeks before are for offload work: run the hit-ratio levers on the event paths specifically — TTLs on the pages the campaign links to, key hygiene against the campaign's own tracking parameters (the marketing UTMs for the event are a classic self-inflicted fragmentation), and an honest look at whether the event pages themselves can be cached as HTML even briefly — at spike request rates, a 30-second page TTL absorbs enormous load. Then pre-position: warm the cache in the event geographies as the doors open, and enable serve-stale generously so that if the origin does struggle, the edge keeps serving yesterday's answer instead of an error.
Harden the origin path
For the traffic that must reach origin, narrow and reinforce the corridor: origin shield on, so a global spike converges to one fetching location; request collapsing confirmed, so a thousand simultaneous misses for the sale page become one origin fetch; keep-alive between edge and origin verified, so the origin isn't also running a handshake factory; and sensible edge-side timeouts with a tested error page, so a struggling origin degrades into something branded rather than a raw gateway error. Scale the origin too — the corridor still carries the uncacheable transactions — but scale it against the post-offload forecast from step one, not against the raw spike; that difference is usually the event's entire infrastructure budget.
Pre-stage the degradation plan
Decide now, calmly, what gets turned off if the origin reddens anyway — because deciding at peak, at 2 a.m., under a hashtag, produces bad decisions. A degradation ladder, written and pre-approved: first rungs cheap and invisible (lengthen TTLs on semi-static content, let serve-stale carry more), middle rungs visible but survivable (disable recommendations, search suggestions, anything personalized that turns cacheable pages into uncacheable ones), last rungs the honest emergency (a static holding version of key pages, pre-built and already cached at the edge; a waiting room if transactions must be metered). Each rung names its trigger metric, its switch, and who may pull it. The test of a good ladder is that the person on call can execute rung three without waking anyone.
Vendors, rehearsal and the day itself
Tell your CDN the date, the geography and the forecast multiple — large platforms absorb most spikes unannounced, but a heads-up gets your event on the provider's radar, surfaces any commercial surprises in advance, and matters doubly for very concentrated regional spikes; confirm support-escalation paths while you're at it. Rehearse once: a load test through the full delivery path (with the provider's blessing) that validates the offload numbers and fires the degradation ladder's first rung on purpose. Then run the day like an operation, not a vigil: a war-room channel, named roles, and a one-screen scoreboard — edge requests, hit ratio on event paths, origin request rate and latency, error rate, log-derived and live. Afterwards, the retro captures the real peak versus forecast and which rungs fired; that document is next event's step one, and it is how spike days become progressively boring — which is the entire goal.