Black Friday readiness: making your shop survive the spike
Your shop runs fine for 364 days a year. Then Black Friday arrives, traffic goes 20x, and the wheels come off at the worst possible moment. Here is the timeline that prevents it.
The thing about Black Friday failures is that they are almost never surprising in hindsight. Afterwards, everybody knows exactly what broke: the search endpoint that was always a bit slow, the database that had no headroom, the third-party script that timed out. All of it was visible in October. Nobody looked, because in October the site was fine.
So this is organised as a countdown rather than a list, because the timing is the actual advice. Doing the right thing in the wrong week is how teams end up making risky changes on the Wednesday before.
Six weeks out: find the ceiling
You cannot prepare for a load you have not measured. The first job is finding out where your shop actually breaks, and it must happen early enough that fixing what you find is calm work rather than emergency work.
Load-test against a copy of production with realistic data volumes — a staging database with 40 products will happily serve traffic that would destroy your real catalogue. Ramp gradually and watch for the point where response times start climbing while throughput stops. That inflection is your ceiling, and it is nearly always lower than people guess.
Test the journey, not the homepage. Anyone can serve a cached homepage under load. What matters is browse → product → add to cart → checkout, in that proportion, because the last two are the uncacheable ones and they are where you will fall over.
The most common Black Friday failure is not the web server — it is the database, drowning in cart and session writes it cannot cache its way out of. Watch database connections and lock waits during the test, not just CPU. A web tier that scales horizontally in front of a database that does not is the classic shape of a bad afternoon.
Four weeks out: make the shop cacheable
The single biggest lever is how much of your traffic never reaches your origin at all. Every request answered from the edge is capacity you did not have to buy.
Cache at the edge
- Homepage, campaign landing pages
- Category and product pages
- Search results, if you can tolerate short TTLs
- All images, CSS and JavaScript
Always bypass
- Cart and checkout
- My Account and order history
- Anything with a session cookie present
- Live stock counts, if you show them
Get the bypass rules exactly right now, not during the rush. The mechanism is cookies: your platform sets a recognisable cookie once a shopper has a cart or logs in, and the cache bypasses on its presence. Test it properly — add something to a cart, browse away, come back, confirm the cart survived and that a fresh incognito window still gets a cached page.
Then check your cache hit ratio and keep checking it. If it is below 85% on a shop, find out why before the traffic arrives rather than after.
Two weeks out: the safety valve and the freeze
Two things happen here, and both are about what you do when preparation is not enough.
Put a waiting room in place and test it. Not necessarily switched on — configured, tested, and one toggle away. It is the only mechanism that degrades gracefully when demand genuinely exceeds capacity, and the worst time to configure one for the first time is while the site is falling over.
Start the change freeze. No new plugins, no theme changes, no dependency upgrades, no "quick" migrations. Every Black Friday post-mortem features a change someone made in the last fortnight that seemed harmless. If a change is genuinely required, it ships early in the week and gets a full day of observation.
The week before: rehearse the boring things
Confirm who is actually on call
With phone numbers, not Slack handles. Establish who can make the decision to enable the waiting room without asking anyone.
Check certificate expiry dates
A certificate expiring during your busiest week has happened to more shops than anyone admits.
Verify your rollback works
Not that it exists — that you have run it recently and know how long it takes.
Raise TTLs deliberately
Longer cache lifetimes than usual for the campaign period, with a plan for purging when prices change.
Warm the cache before you announce
Crawl your campaign pages so the first thousand real visitors are not all cache misses arriving simultaneously.
Write the "we are busy" message in advance
Whatever the queue page says, write it calmly now rather than under pressure later.
On the day: watch three numbers
Dashboards during a spike are mostly noise. These three tell you what is actually happening:
Origin requests per second is the one to trust. If total traffic triples and origin traffic barely moves, your caching is doing its job and you can relax. If origin traffic tracks total traffic, you are effectively running without a CDN and should find out why immediately.
Resist the urge to optimise live. A change that is obviously correct at 2pm on Black Friday has a much worse track record than doing nothing. The waiting room is your intervention; use that, and leave the code alone.
Frequently asked questions
How do I prepare my ecommerce site for Black Friday?
Work backwards from the date. Six weeks out, load-test the full purchase journey against production-sized data to find where the site breaks. Four weeks out, maximise what can be cached at the edge and verify that cart and checkout correctly bypass the cache. Two weeks out, configure and test a waiting room and begin a change freeze. The week before, warm the cache, confirm on-call arrangements and verify rollback.
How much traffic should I expect on Black Friday?
Shops commonly see 10 to 30 times a normal day, concentrated into a few hours rather than spread evenly. The multiplier matters less than the concentration: the same number of visitors arriving over 24 hours would be unremarkable, and arriving in 90 minutes is what breaks things. Use your own previous years as the baseline and plan for the peak hour, not the daily total.
What usually breaks first under Black Friday load?
The database, in most cases. Web servers can be scaled horizontally and cached in front of, but cart writes, session writes and inventory updates all converge on a single database that cannot be cached away. Watch connection counts and lock waits during load testing rather than only CPU, since the failure often appears as queuing rather than saturation.
Should I freeze deployments before Black Friday?
Yes, typically starting two weeks out. Almost every Black Friday incident post-mortem identifies a change made shortly beforehand that seemed low risk. If a change is genuinely necessary, ship it early in the week so it gets a full day of real traffic under observation, rather than in the final days when there is no time to notice a problem.
Can a CDN handle Black Friday traffic on its own?
It handles the cacheable majority, which is usually most of it — browsing, product pages, images and assets. It cannot cache cart, checkout or account pages, so your origin still has to serve those. The realistic goal is that origin load stays roughly flat while total traffic multiplies, which leaves your database free to handle the writes that actually generate revenue.
Black Friday rewards the boring work you do six weeks early. Find your ceiling with a realistic load test, cache everything that is not personal, have a waiting room configured and tested, freeze changes, and on the day watch origin requests per second above everything else. The goal is a day where nothing interesting happens.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
