Matt Park

Ecommerce Engineering

Peak season is an engineering deadline, not a marketing one

By 10 minute read

Editorial illustration of an ecommerce checkout pipeline being load-tested ahead of peak season.

Peak season arrives on marketing’s calendar. It lands on engineering’s stack long before the first hero banner goes live.

By the time a campaign brief says “Black Friday,” several engineering clocks are already running: load-test cadence, checkout hardening, deploy discipline, dependency budgets and the quiet work of making sure a Tuesday evening in November behaves like a revenue event rather than an incident. Marketing owns the message. Engineering owns whether the message converts when traffic stops being polite.

That distinction matters because peak is not one day anymore. In the UK, Black Friday through Cyber Monday 2025 delivered roughly £3.8 billion in online spend across four days, with Adobe Analytics reporting Black Friday itself at about £1.16 billion — the single biggest online shopping day of the year. Order volumes rose through the whole window; delivery data from Ingrid showed Sunday 30 November peaking at 16.9 orders per second, with evening surges on multiple days. Scurri reported Cyber Monday order volume running about 70% higher than Black Friday, with a shared conversion peak around 5pm on both days.

The storefront does not experience a calendar. It experiences concurrent buyers, promotion logic, inventory contention, payment latency and whatever third-party scripts accumulated since June. If those systems are still “planned” in September, you are not preparing for peak. You are negotiating with it.

Why this is an engineering deadline

Marketing deadlines are narrative: launch the offer, open the landing page, send the email. Engineering deadlines are behavioural: can a buyer search, configure a variant, apply a code, pay and receive confirmation while everyone else is doing the same thing?

Outages get attention. Degradation is more common and more expensive than teams admit. Shopify’s own site-speed analysis suggests conversion tends to be about 3.5% lower for every 100 milliseconds of added load time. Field data studies of large retailers tell a similar story at scale: among the most-visited online stores, good Interaction to Next Paint on mobile falls to roughly 45% in CrUX — not because the sites fail to load, but because they stop feeling responsive under real main-thread pressure. Across the wider web, HTTP Archive’s 2025 performance analysis found 48% of mobile origins passing all three Core Web Vitals. Ecommerce results vary sharply by platform: its ecommerce chapter reported mobile pass rates ranging from 35% for WooCommerce and Magento origins to 76% for Shopify. Loading is often the visible gap, but checkout also lives in interaction and dependency latency.

Peak magnifies both failure modes. A five-minute checkout stall at 3pm on a random Tuesday is annoying. The same stall at 8pm on Black Friday week is revenue, wasted ad spend and support load you cannot buy back on Cyber Monday. In a 2022 survey of 200 senior ecommerce decision-makers at UK businesses with more than £10 million in revenue, respondents estimated an average 10% revenue loss from downtime and performance issues over the previous two years — a figure that sounds abstract until you map it onto four concentrated days.

Platform scale is not immunity. Shopify’s BFCM 2025 peak — $14.6 billion in merchant sales, 489 million edge requests per minute and up to 40,000 checkout starts per minute — is often quoted as proof that “the platform handles it.” That is true at the infrastructure layer. Your checkout still runs through your theme, your apps, your integrations, your promotion rules and your catalog logic. Merchant-level failures during peak are rarely “Shopify is down.” They are database lock contention on a custom app, a tax API timing out, a tag manager change that doubled main-thread work, or a code path that only breaks when basket updates spike.

The calendar marketing sees vs the calendar engineering needs

Black Friday 2026 falls on 27 November, with Cyber Monday on 30 November. From early September that is roughly twelve weeks — enough time if you treat it as an engineering programme, not a November ticket queue.

Marketing calendars cluster around asset delivery: creative, copy, landing pages, CRM segments, influencer drops. Engineering calendars need lead time that does not compress:

  • Load-test cadence — merchant teams should start at least eight to twelve weeks before peak so tests can fail, be fixed and run again. For comparison, Shopify says its own engineering team prepares for nine months, load-tests at 150% of projected peak and runs game-day exercises ahead of BFCM.
  • Checkout and payment paths — sandbox gateways, realistic basket sizes, promotion combinations and inventory states need rehearsal before the real event. Payment and fraud dependencies are third-party systems with their own latency tails.
  • Deploy and change discipline — leading into BFCM, Shopify historically narrows from dozens of daily deploys toward feature and code freezes. Custom stacks need an equivalent contract: what still ships in October, what needs exception approval in November, and who can call a halt.
  • Observability baselines — you cannot spot a regression on the night if you do not know what “normal” looked like in September. Dashboards should follow buyer journeys, not only CPU graphs.

None of those clocks wait for creative approval. They are why “we’ll harden in October” is a plan written in the wrong department.

Load testing: model the revenue path, not the homepage

Homepage load tests are theatre. Peak revenue concentrates on a handful of journeys: campaign landing → product detail → variant selection → basket → shipping → payment → confirmation. If 80% of spike traffic lands on three hero SKUs, your test mix should reflect that skew.

A useful peak load test looks like a buyer, not a bot counting requests:

  • Mix guest and authenticated checkout, mobile and desktop, cached and cold sessions.
  • Include promotion codes, shipping calculations, tax lookups and loyalty redemption if production uses them.
  • Exercise inventory writes and basket updates concurrently — database locking remains one of the most common causes of checkout failure under load.
  • Run third-party dependencies in sandbox or stubbed modes with production timeout budgets. A payment provider that adds 400ms at p95 under load is a promotion problem and an engineering problem.
  • Ramp baseline → expected peak → sustained peak → 150–200% spike. Any material increase in 5xx responses under sustained target load is a stop-ship defect, not a tuning note.

Track the same metrics you will watch on the night: p95 latency on add-to-cart and checkout steps, error rate, queue depth, cache hit ratio, dependency latency and conversion drop-off by step. Set an explicit checkout p95 objective and treat breaches under target load as launch blockers; fix that path before arguing about hero image formats.

Performance is a peak feature

Performance work is often framed as a hygiene task for quieter months. At peak it is part of the product: the “fast checkout” your CRM promises is an INP budget, a script budget and a CDN cache policy.

Third-party scripts deserve explicit treatment here, not a footnote. As I argued in Third-party scripts are an engineering leadership problem, the browser executes the combined portfolio — analytics, chat, experimentation, reviews, payments, consent — regardless of which team commissioned each tag. Peak multiplies that cost because main-thread contention shows up as sluggish size selectors, delayed pay buttons and abandoned baskets that analytics later misattributes to “creative fatigue.”

September is the last comfortable month to remove or defer scripts that cannot justify their place in the checkout funnel. October is for proving the remaining set survives load. November is for refusing new ones unless the rollback plan is written in advance.

Change control when everything wants to ship “before peak”

Peak creates a paradox: the business wants maximum change velocity going into the highest-risk window. Engineering’s job is to convert that energy into controlled risk.

A practical policy many teams stumble toward too late:

  • September — feature complete for peak-critical paths; load tests begin; promotion logic frozen in staging for soak testing.
  • Early October — fix what load tests surfaced; no new checkout dependencies without capacity review.
  • Mid-October onward — exception-only merges on cart, checkout, pricing, inventory and payments; rollbacks rehearsed.
  • Black Friday week — deploys limited to reversions and verified mitigations; war-room ownership published.

AI-assisted development raises the stakes. When diffs look finished faster, the temptation is to merge promotion tweaks and “small” checkout changes closer to the event. That is exactly when the review bar after AI should tighten: higher-risk paths, clearer evidence of manual verification, and explicit rollback steps — not because AI is forbidden, but because peak is the wrong time to discover nobody understood the change.

Run the event like an incident before it happens

Game days are not only for hyperscalers. A half-day exercise in October pays back on the first real surge:

  • Simulate dependency failure — tax, shipping, fraud, search, ERP stock feed — and confirm graceful degradation messages reach customers.
  • Practice toggling feature flags, disabling non-essential scripts and switching to a simplified checkout path if you have one.
  • Validate on-call routes, status-page updates and the difference between “slow” and “down” in customer communications.
  • Confirm synthetic monitoring hits cart and checkout from outside your network, not only homepage pings.

Shopify’s production engineering team uses game days and controlled dependency degradation ahead of BFCM for exactly this reason: peak failures are coordination failures as often as they are code bugs.

What to deprioritise

Peak readiness is also a subtraction exercise:

  • Net-new checkout experiments without a control path you can disable in one action.
  • Large refactors that touch cart state, session handling or pricing engines in the final six weeks.
  • Vendor installs that add JavaScript to every page “just to trial before Christmas.”
  • Load tests that only hit the homepage and declare success.
  • Arguing about platform choice during peak week instead of executing the runbook.

Deprioritising does not mean freezing the business. It means naming what must stay boring so the exciting parts — offers, bundles, urgency — have something solid underneath.

A practical checklist for engineering leads

Use this as a working list from early September through November:

  • Baseline last year’s peak metrics — traffic shape, checkout p95, error budget burn, top SKUs, support themes — and set this year’s targets at 150% or more for testing.
  • Commission journey-based load tests by mid-September at the latest; leave time for two fix-and-retest cycles.
  • Audit third-party script cost on product and checkout templates; remove or defer anything not tied to conversion or compliance.
  • Verify promotion, pricing and inventory rules under concurrent load — including edge cases like stackable codes and out-of-stock during basket update.
  • Publish a change-control policy and exception approver before October campaigns go live.
  • Run at least one game day covering dependency failure and rollback.
  • Build a launch dashboard around funnel steps, not infrastructure vanity metrics.
  • Assign a single incident commander for peak nights; marketing and engineering share the same status channel.
  • Schedule a blameless retrospective in the first quiet week of December while memory is fresh.

The leadership line

Marketing will always experience peak as a story customers tell. Engineering experiences it as a systems proof — a few evenings when polite traffic becomes concurrent contention and every shortcut from June arrives at once.

The useful reframing for cross-functional teams is simple: peak season is not when you discover whether the storefront is ready. It is when you collect the bill for decisions made in August and September. Treat those weeks as an engineering deadline, and the campaign has something worth saying when the traffic arrives.

Currency note: UK spend and order-volume figures reference Black Friday through Cyber Monday 2025 reporting; BFCM 2026 dates and preparation timelines are stated as of 3 September 2026.

Sources and further reading