Getting a store ready for a campaign peak
Cache what you can, tune what you cannot, and rehearse the load before the traffic is real.
Peak trading exposes whatever you were getting away with the rest of the year. The good news is that store traffic is unusually predictable in shape: a lot of browsing, far less cart activity, and a small number of checkouts that absolutely must not fail.
Separate the cacheable from the sacred
Category pages, product pages and content are cacheable for anonymous visitors and should be served from the edge. Cart, checkout and account pages must always be dynamic. Getting this split right typically removes most of the origin load before you add a single server.
Watch for the small things that accidentally personalise a whole page — a cart-count badge or a recently-viewed strip is enough to make a cacheable page uncacheable. Load those fragments client-side instead.
Tune what has to be dynamic
Profile the checkout path specifically. Look for slow database queries, synchronous calls to external services, and anything that writes to the same row on every order. Move email, analytics and fulfilment notifications onto a queue so a slow third party cannot stall a purchase.
Rehearse with real numbers
Estimate peak concurrency from your own history — last year's peak hour multiplied by expected growth is a better starting point than a round number. Load test against a production-like environment, including checkout, and find the breaking point before your customers do.
Plan the day itself
Freeze deployments for the peak window, agree who is on call and how they are reached, and prepare a graceful degradation plan: what you switch off first if the store comes under strain — recommendations, live search, or non-essential widgets — so that browsing and buying keep working.
Cache aggressively, make checkout boringly reliable, rehearse at realistic volume, and decide in advance what you would turn off. Peak days should be commercially exciting and operationally dull.
Talk to our team
