Ecommerce Load Testing: 2026 Black Friday Checklist

Black Friday has a fixed date. Your sale does not move because your checkout melted at 9:01 AM. That single fact is what makes ecommerce load testing different from the generic “run some load and see what happens” advice you find everywhere. You are not testing whether the site is fast on a normal Tuesday. You are testing whether the browse-to-payment funnel survives a sharp, marketing-driven spike against third-party dependencies you do not control, on a day where every minute of downtime is measured in lost revenue.

This is a deadline-driven, week-by-week readiness checklist built around the funnel that actually breaks under load: cart, checkout, payment gateway. It is the plan we run with ecommerce and platform teams who come to us six weeks out saying “we need to be ready for Black Friday.” Work through it in order and you walk into your sale with a tested breaking point and a runbook, not hope.

Modeling peak traffic from your historical data

You cannot test for a number you have not estimated. The first job is to turn last year into a target.

Pull last year’s peak from your analytics and APM: requests per second, concurrent sessions, and conversion rate during the busiest hour of the busiest day. Not the daily average, not the monthly total. The single worst hour is your baseline, because that is the hour that decides whether this year goes well.

Then apply a growth multiplier for this year’s reality: bigger marketing spend, a larger customer base, a more aggressive discount. If you grew the list 40% and doubled ad spend, your peak is not 10% higher. Once you have a projected peak, add headroom and test to 1.5-2x projected peak, not exactly to it. Testing to your estimate proves nothing, because your estimate is wrong. Testing to double it tells you how much margin you actually have when reality overshoots.

Model the spike shape, not just the average. Sale traffic does not arrive as a gentle curve. It arrives as a sharp ramp the instant the email goes out or the countdown hits zero. A system that handles 5,000 sustained users fine can still fall over when 5,000 users arrive in ninety seconds, because connection pools, autoscalers, and cold caches all have to catch up at once. Your load profile needs a steep ramp, not a slow climb.

Finally, separate browse traffic from buy traffic. Most users window-shop, and product pages are cacheable and cheap. The checkout path is the expensive, stateful, failure-prone one, and it is a smaller share of total traffic but the entire share of your revenue. Model both, but weight your scenario design toward the buy path. Our capacity planning guide walks through turning these numbers into a concrete load profile.

The cart and checkout funnel scenarios that actually break

Hitting the homepage with 50,000 virtual users proves your CDN works. It tells you nothing about whether people can buy. The scenarios that matter are the ones that exercise state.

Script the full funnel as one virtual user journey: browse, add to cart, checkout, payment, confirmation. Each virtual user should carry a session, hold a cart, and complete an order, because the failures live in the transitions between steps, not on any single page. A tool like k6 handles this well at protocol level for reaching real request volume, and pairing it with real-browser testing on a subset of users catches the front-end behavior protocol load misses.

Test inventory contention directly. Thousands of users trying to buy the same limited-stock item is the classic sale-day killer, because that purchase serializes on a single database row or lock. It does not matter that your servers have spare CPU if every checkout for the doorbuster product is queued behind one row-level lock. Script a scenario where a large share of virtual users all target one low-stock SKU and watch what happens to checkout latency.

Test coupon and promo-code validation under load. A discount engine is a textbook single point of failure during a sale, precisely because a sale is when every single user hits it. If promo validation does a synchronous lookup against a service that was sized for normal traffic, it becomes the bottleneck for the entire checkout flow.

Test session and cart persistence under spike traffic, including cart recovery after a transient error. Users will hit a hiccup, retry, and expect their cart intact. If a transient failure silently empties carts, you lose the sale even though the system “recovered.” See our writeup on common load testing mistakes for the funnel-scripting errors that make these tests lie to you.

Third-party and payment-gateway dependencies

Here is what generic load-testing guides skip: most of your checkout latency at peak comes from systems you do not own.

Your payment gateway has its own rate limits. Stripe, PayPal, and Adyen each enforce request ceilings, and the only way to find yours is to load test against the real gateway sandbox. Discovering your gateway’s rate limit during your actual Black Friday sale is the single most expensive way to learn it exists. Their sandboxes are built for exactly this; use them.

Remember the synchronous tax, shipping-rate, and fraud-check APIs. Every checkout typically makes blocking calls to compute tax, fetch live shipping rates, and run a fraud score. Each of those is a third-party round trip on the critical path, and any one of them can become the bottleneck that drags p99 checkout latency past the point where carts abandon.

Decide deliberately what to mock versus hit live:

Run both. Mocking finds your own ceiling; hitting the sandbox validates timeout and retry handling against reality.

Then plan graceful degradation before you need it: queue-based checkout that holds users in line instead of dropping them, honest “try again in a moment” messaging, and circuit breakers that trip when a third party slows down so one slow dependency does not cascade into a full checkout outage. Decide this in advance, because you cannot architect a circuit breaker at 9:05 AM on sale day.

CDN, cache, and database behavior under sale traffic

Your origin should be doing as little work as possible at peak. Verify that it is.

Check cache-hit ratios on product and category pages. A cold cache at sale open will melt your origin, because the exact moment traffic spikes is the moment every cache is being populated for the first time. If your hit ratio is healthy on a normal day but you flush caches as part of your sale deploy, you have engineered a guaranteed origin overload at the worst possible second.

Test the cache stampede scenario explicitly. A popular product’s cache entry expires, and 10,000 simultaneous requests for that product all miss the cache and hit the database at once. This is one of the most common sale-day origin failures, and it is invisible until you reproduce it. Script a test where a hot key expires under load and confirm your cache uses request coalescing or a stale-while-revalidate strategy so one miss does not become ten thousand.

Confirm the CDN is actually serving static assets and images at peak, so origin bandwidth stays reserved for dynamic checkout. It is easy to assume the CDN is doing its job and discover under load that a misconfigured cache header is sending image requests straight to origin, eating the bandwidth your checkout calls needed.

Watch the database connection pool and read-replica lag as write traffic spikes. Orders are writes, and a sale generates a flood of them. Connection pool exhaustion and replica lag both show up only under sustained write load, and both will quietly break checkout while every dashboard says CPU is fine. Our load testing guide covers instrumenting these database-layer signals during a run.

Setting p99 targets and rollback thresholds

A load test without a pass/fail target is just a stress demo. Before you run anything, decide what “ready” means in numbers.

Define the latency budget for checkout specifically. A slow product page loses interest; a slow checkout loses the sale. Those are different stakes and deserve different budgets. A 2-second product page is annoying. A 2-second checkout step, repeated across five steps, is an abandoned cart. Set a tight, explicit budget for every step of the buy path.

Set p99, not average, targets at projected peak. Averages hide the tail, and the tail is exactly where abandoned carts live. If your average checkout is 400ms but your p99 is 6 seconds, one in a hundred customers, at the busiest hour of your year, is staring at a spinner and leaving. Test against p99 so the slow tail is a failure condition, not a footnote.

Pre-agree your rollback and feature-flag thresholds. At what error rate or latency do you shed load, disable product recommendations, turn off personalization, or switch to a static fallback page? These are business decisions, and they must be made before the sale, calmly, not improvised at peak by a stressed on-call engineer. Wire each threshold to a specific, pre-approved action.

Finally, document the breaking point and the bottleneck so on-call has a runbook before the sale, not during it. The deliverable of all this testing is not “it passed.” It is a one-page runbook: here is where it breaks, here is the first thing to fail, here is the lever that buys headroom, here are the thresholds and what to do when each one trips.

The 6-week peak-readiness countdown

This is the framework that maps calendar urgency to concrete work. Six weeks is the minimum, because everything you find in testing needs time to fix and re-test.

The discipline that makes this work is the re-test in week 2. A bottleneck you “fixed” in week 4 but never re-tested is a bottleneck you are hoping you fixed. The countdown bakes in the second run that turns hope into evidence, and it leaves week 1 clear for a change freeze instead of a scramble.

If you start this countdown later than six weeks out, you are choosing between testing and fixing. You rarely have time for both. That is why the scope call happens early.

Get ready before the deadline, not during it

Black Friday does not negotiate. The teams that sail through peak are the ones that modeled the spike, broke their own checkout in a sandbox, found the inventory lock and the gateway rate limit on a quiet Tuesday in October, and walked into sale day with a runbook taped to the wall.

Book a peak-readiness load test 6 weeks before your sale - a free 30-minute scope call with our load testing engineers. We will model your peak traffic, script your real checkout funnel, pressure-test your payment gateway and database, and hand you the breaking point and runbook before the date that does not move. See our Pre-Launch Load Test and Capacity Assessment services for how the engagement runs.