launching a commerce platform five weeks before black friday

date: November 28, 2025

The final storefront went live five weeks before Black Friday. Five days later, the first serious campaign peak showed us how the new platform behaved under real traffic. There was no long bedding-in period before the most important commercial weeks of the year.

Black Friday was the first immovable checkpoint, but not the last. The high season continued into an annual championship event that would produce the platform’s busiest traffic. We had to prepare a platform we barely knew for that final peak.

Problem: Historical traffic told us how busy the business could become, but not how a new frontend, gateway, and commerce engine would behave together. The old estate spread country storefronts across roughly a dozen commerce instances. After the phased commerce replatform, the new platform concentrated them on one commerce engine behind a shared gateway.

Solution: We ran a delivery-led readiness programme that combined production evidence, caching and performance work, six load-test profiles, temporary capacity, and event operations. Every test had to end in a decision about headroom, scaling, or risk.

Historical demand set the forecast. Production provided proof

The previous platform gave us useful planning data from earlier peaks, including sessions, orders, and expected growth. That established the commercial risk.

It did not establish technical capacity. Replatforming changed request amplification, cache behaviour, frontend rendering, gateway traffic, and dependency limits. Consolidating multiple commerce instances into one also concentrated load. Adding the old numbers together would have produced false confidence.

The first live campaign became our baseline. We used that observed behaviour to set the initial test target, then built the readiness plan backwards from Black Friday and the annual championship period that followed it.

That first target was a planning floor, not a fixed ceiling. Every production event gave us better evidence, so we kept raising the test volume until the gateway had enough proven headroom for the final event.

Production traffic shortened the learning cycle

Initial releases quickly showed which assumptions were wrong. During one evening peak, the gateway remained healthy while frontend concurrency caused severe latency. More backend machines would not have solved it.

This is why the plan treated early production as part of testing. Incidents, traces, cache hit rates, scaling events, and slow user journeys fed the next two-week priority review. The CTO, engineering director, and I looked at the evidence, agreed the biggest risk, and funded the next correction. Stability work had an explicit place in the plan instead of competing with feature delivery through informal escalation.

As Solution Delivery Director and Solution Architect, I connected delivery governance to the platform design. My job was to make sure every capacity risk had an owner, evidence, a deadline, and a fallback. The specialist teams still owned implementation within those boundaries.

The programme covered code stability, uptime measures, and performance. That meant cleaning up expensive paths, improving caching, proving autoscaling, adding synthetic checks and alerts, preparing frontend and backend playbooks, and agreeing who could make a go or no-go decision.

Capacity planning needed one unit and a named boundary

We used requests per second, or RPS, when comparing throughput across the platform. For sustained backend traffic, the per-minute equivalent can make the scale easier to grasp. The unit alone is not enough, though. Every figure still needs a named measurement point.

Frontend, gateway, and commerce-engine traffic describe different parts of the landscape. The frontend handles page rendering, assets, security checks, and browser behaviour. Caching and routing reduce or reshape the traffic that reaches the gateway, and the gateway may combine several downstream operations.

This is why the capacity model named the boundary. Frontend and gateway throughput can use the same RPS unit without pretending they are equivalent workloads.

Each load test answered a different question

We did not have one generic load test. We used six distinct scenarios, each answering a different question in the readiness plan:

• Smoke: prove the environment, credentials, test data, endpoints, and measurements before generating load.
• Average load: establish steady-state behaviour once caches, connection pools, and autoscaling had settled.
• Peak: hold the expected high-season volume and verify that latency and errors stayed within their thresholds.
• Spike: double traffic quickly and test whether warm capacity and autoscaling reacted before customers noticed.
• Stress: go beyond the expected peak to find the platform boundary and measure the remaining headroom.
• Soak: sustain traffic for hours to expose memory growth, connection leakage, cache churn, queue buildup, and rate limits.

Full user journeys ran across these profiles. Browsing alone can make a platform look healthy while login, account history, cart, or checkout calls struggle. We therefore mixed anonymous browsing, authenticated traffic, carts, and browser tests from multiple European regions.

The combination mattered. Peak and soak tests prepared the gateway for an hour of sustained demand, while spike tests prepared the frontend and scaling layers for the much sharper bursts that happened inside that hour.

More machines bought time, but the plan created confidence

The first average-load run began with too little warm gateway capacity. Autoscaling eventually added enough machines, but useful capacity arrived too late and latency breached its threshold. Repeating the run with a higher warm baseline reduced latency and removed nearly all errors.

That changed our peak profile. We raised the production baseline before the event and allowed a higher temporary maximum. This bought time while optimisation continued. The platform’s shared caching strategy stopped every new gateway task from sending a cold burst to the commerce engine, while request, CPU, and memory signals controlled scaling.

We also prepared for failure. Synthetic checks, alerts, ownership, rollback paths, and service-desk escalation were tested before the commercial event. Zero downtime cannot be promised by a diagram. It comes from proving the likely paths and deciding how the team will respond when an unlikely one appears.

The final high-season peak stayed inside the tested headroom

The final gateway stress test went beyond the expected peak while staying within its latency and error thresholds. Black Friday then passed without a critical platform incident, but the readiness programme continued through the rest of the high season.

During the busiest high-season event, the backend gateway handled about 66,000 requests per minute, or 1,100 RPS. This was the sustained load the preparation programme had been designed and tested to handle.

At the same event, the frontend handled roughly 5,000 RPS. The same measurement window contained 2,451 distinct visits, showing how one active visit can generate many frontend requests. The two RPS figures explain why we tested both sudden spikes and sustained load, and why every capacity number needs a named boundary.

Result: The platform carried the final high-season peak within the headroom we had tested. The preparation was not one oversized machine or one successful stress test. It was the cycle of live evidence, optimisation, six distinct load profiles, scaling changes, and operational rehearsal.

The lesson I would copy is the operating rhythm. Launch early enough to learn from real traffic, turn every observation into a ranked delivery decision, and keep raising the test target as production evidence improves. Temporary headroom is worth buying when the commercial downside is larger than the infrastructure bill.

I worked on this as Solution Delivery Director and Solution Architect at rb2.