Preparing your data pipeline for the Christmas retail peak: a UK checklist

Every retail data team in the UK knows the shape of the year. January is quiet, summer is steady, and then the last Friday in November arrives. For about six weeks afterwards your pipelines run at two or three times their normal volume. The failures are rarely dramatic. An overnight batch that usually finishes at 04:00 is still grinding away at 09:00. A stock feed drops a handful of SKUs and the website cheerfully promises next-day delivery on something that sold out in Leeds on Tuesday. A trading dashboard reports sales up sharply because a duplicate feed inflated the numbers, and nobody notices until the merchandising meeting.

None of that is unavoidable. Teams that get through the peak comfortably tend to be the ones that spent October being deliberately boring: testing, timing, documenting and deciding in advance what to switch off. Here is a checklist for the weeks before it starts.

Map your own peak before you plan for it

Black Friday is not one event, and it is not the only one. Depending on what you sell, the pressure points arrive in a different order. The Black Friday weekend and Cyber Monday stress traffic, event streams and API limits. The first two weekends of December stress fulfilment and Click and Collect promises as delivery cut-offs approach. Boxing Day and the days after stress batch processing, returns and customer service tooling, often with a thinner on-call rota than usual.

Write those peaks down with dates and note which systems each one hits hardest. Then ask, for each:

• Which pipeline is nearest its limit that day, and how would I know?
• Who is on call, and do they have access to the levers they will need at 06:00?
• What delay is acceptable before someone is woken up?
• Which third parties sit in the critical path, and what are their support hours over the bank holidays?

Load testing that tells you something

A load test that hammers a single endpoint is a comfort blanket, not evidence. Replay a realistic version of last year's busiest hour instead: the same payload sizes, the same skew towards a handful of popular SKUs, the same mix of reads and writes. If normal load is one unit, test at three or four. Peaks are rarely gentle.

Test the whole chain, including the parts you do not own. Your queue may scale beautifully while your warehouse connection pool, a payment provider's rate limit or a carrier's tracking API gives up at the same moment. Watch queue depth and drain time as closely as latency: the question is not only whether the system survived the spike, but how long the backlog took to clear afterwards.

Test the configuration you will actually run

There is little point proving that a service scales if the autoscaling ceiling is set low, a cache is disabled, or the change freeze means you cannot deploy the version you tested. Load test in the December configuration, and include at least one exercise where you deliberately break something — kill a consumer, block a downstream API — to see how both the system and the on-call rota respond. If you replay production data, anonymise it and check with whoever owns data protection that holding that copy for testing is acceptable.

Stock feeds are where peak breaks first

Inventory is the most operationally sensitive data a retailer holds, and usually the messiest. Feeds arrive from stores, distribution centres, marketplace partners and, occasionally, a spreadsheet someone updates on a good day. Under peak volume, the small assumptions baked into those feeds turn into customer-facing errors. The usual suspects:

• Cadence: a feed refreshing hourly is fine on a quiet Tuesday and useless during a flash sale. Know the latency of each feed, and publish it where the business can see it.
• Last-write-wins conflicts: point-of-sale and online systems editing the same number. Decide which source wins, per channel, and write it down.
• Partial failure: a job returning a success code while loading part of the rows. Validate row counts and totals, not just exit codes.
• Unknown stock: decide now whether to show an item as unavailable or hide it entirely when the feed is stale. Both are defensible. Leaving it to a developer at 22:00 is not.

Make feeds idempotent and replayable, so a failed run can be reprocessed without duplicating or zeroing stock. Then alert on the data rather than the job: if online orders for a SKU exceed recorded availability by a wide margin, that is a data problem long before it becomes a customer service problem.

Real-time dashboards: decide what deserves to be live

During peak, more people look at dashboards than at any other time of year, and every one of those queries competes with production. Not everything needs to be live. A trading team watching conversion and payment failures needs seconds. Merchandising usually needs minutes. Finance can wait until the morning. Tier your dashboards accordingly and say so out loud, because labelling something "real-time" sets an expectation you then have to meet.

A few practical moves:

1. Pre-aggregate the figures that do not need row-level detail.
2. Put a freshness indicator on every tile, so nobody acts on a number from three hours ago.
3. Reduce refresh frequency on non-critical views for the peak period, rather than letting everyone pull a full refresh.
4. Alert on a short list of things a human can actually do something about.

If you cannot answer "how stale is this number?" for every figure on a dashboard, that is the first thing to fix.

Check concurrency limits too. Ten people opening a dashboard is fine; a hundred opening it during a live incident is a different test, and one worth running before December.

Freezes, fallbacks and the human bits

A change freeze is useful, but a total freeze is a trap: you still need to be able to fix a broken feed on 22 December. Freeze schema and architecture changes, and keep a narrow, well-tested path for fixes with named approvers and a short list of who can deploy.

Agree your degraded modes in advance. Which non-essential jobs can be paused to free capacity — a recommendation rebuild, a nightly segmentation, an enrichment feed? Which dashboard can drop to 15-minute refreshes? Write these down as decisions, not ideas, so nobody has to invent them under pressure.

Then do the unglamorous human work: a runbook covering the five most likely failures with the first three steps for each; two named contacts per system; a handover note for every on-call shift; and an escalation route to third-party support that you have actually tested. Many vendors run reduced support between Christmas and New Year, so confirm their hours before you need them.

The week before: a short checklist

• Load test the December configuration at three to four times normal peak.
• Confirm queue depth, drain time and autoscaling ceilings for every critical pipeline.
• Publish feed latency and a freshness indicator on every trading dashboard.
• Validate stock feeds on row counts and totals, not exit codes.
• Confirm degraded modes, each with an owner and a trigger.
• Check third-party support hours, escalation routes and rate limits.
• Brief on-call staff and confirm they have access to the levers they may need.
• Book a short daily stand-up for the peak period, with a named owner.
• Decide in advance who speaks to the business when a number looks wrong.

None of this is glamorous, and much of it will feel unnecessary on a quiet Tuesday in October. That is rather the point. The teams that sail through December rarely do anything clever; they simply do the boring work early, while there is still time to fix what the tests reveal.

Photo: Marvin Machler / Pexels