Your Black Friday Is Decided in September
BFCM 2025 ran at 4.2x normal traffic and $11.5B on Shopify alone. The outage is never in the code you were nervous about. Here is the boring playbook.
It is August. Your Black Friday is already mostly decided.
Not by the campaign, not by the discount, but by decisions you are making right now about what you are allowed to deploy in November, and whether anyone has ever tested what happens when four times the usual traffic arrives at once.
The numbers that should set your expectations
BFCM 2025 was not a gentle year. Shopify alone moved $11.5 billion, up about a quarter on the year before. Traffic on Black Friday ran at roughly 4.2x a normal day, and Cyber Monday at about 3.5x.
Infrastructure-side the picture is similar. Vercel served over 56.9 billion requests from cache across the weekend, verified 2.4 billion human interactions, and blocked over 415 million bot attempts. That last number is the one people forget: a meaningful slice of your peak traffic is not customers, and it arrives at exactly the same moment they do.
One thing did shift, and it works in your favour: promotional windows keep getting longer, so the load is spreading out rather than landing entirely on two days. The spike is less vertical than it was in 2020. It is still a spike.
The failure mode is almost never the thing you feared
Nobody's Black Friday dies because React was slow. It dies because a third-party script times out and blocks checkout, or a promo code path nobody tested throws on an edge case, or an admin panel falls over and support goes blind.
Shopify itself had a wobble in 2025 - merchants briefly locked out of their admin dashboards. Sales barely noticed, which is exactly the point: the storefront and the tools you use to run it fail independently, and you should plan for both.
The pattern I have seen repeatedly is that the outage is never in the code you were nervous about. It is in the integration you forgot was on the critical path.
The playbook, which is deliberately boring
Freeze what can break. Keep unlocked what you might need. From early November, stop shipping dependency updates, refactors and anything touching checkout. But do not freeze feature flags, observability, search or payments configuration - those are the levers you will need at 2am. A freeze that locks your own controls is worse than no freeze.
Put a kill switch on every promo and every third party. Every banner, every countdown, every recommendation widget, every analytics script. If it can be turned off from a dashboard without a deploy, it cannot take you down for more than a minute. If turning it off requires a build, it can.
Load test the path, not the homepage. Most load testing hits the front page, which is cached and therefore fine. Test the uncached, stateful path: add to cart, apply promo code, checkout, payment callback. That is where things actually queue up and fall over.
Rehearse the rollback until it is boring. Not "we have a rollback plan." Actually do it, on a normal Tuesday, with the person who will be on call. Time it. If your rollback takes twenty minutes and nobody has run it this quarter, you do not have a rollback, you have a document.
Decide who decides. The costliest minutes in an incident are the ones spent working out who is allowed to switch off the promo. Name that person now, in writing, and make sure they will be awake.
What is actually worth optimising
If you only have time for a few technical things before November:
The checkout path end to end, under realistic concurrency. Not synthetic Lighthouse runs on a warm cache - real sessions, real payment sandbox, real promo logic.
Third-party budget. Count every external script on your critical pages, get their real-world timing, and cut or defer anything that cannot justify itself. This is usually where the largest, cheapest wins are.
Your observability at 4x. Dashboards that are readable at normal traffic often become useless at peak, and alerting thresholds tuned for Tuesday will either scream continuously or stay silent. Test the alerts, not just the app.
The uncomfortable part
Most of this is not engineering work, it is decision work: what you are allowed to change, who can flip which switch, what you will sacrifice first if things go wrong. Teams tend to defer it because it is not fun and does not demo well, and then rediscover in November that the technical readiness was never the bottleneck.
Boring beats heroic at 2am. Every time.
I work with teams on performance and reliability before the traffic arrives, not during it - load testing, third-party budgets, and the architecture decisions behind them. Details here.