E-Commerce Checkout Load Test: Black Friday

BFCM checkout fails differently than the rest of the year. The inventory row you decremented at 5 RPS deadlocks at 500; the third-party tag that added 80ms in October adds 2s when its CDN browns out. This template loads the funnel the way a flash-sale day shapes it — cart mutation, payment init, order-create — not isolated page hits.

Inventory decrement under concurrency

Magento's catalog_product_entity + cataloginventory_stock_item hot row pattern collapses when 2,000 carts hit the same SKU inside a 30-second window. Same story on stacks wrapping SELECT ... FOR UPDATE around stock reservation. Hammer a small SKU set (10-50 products) so contention surfaces — even distribution across a catalog hides the deadlock. Async reservation moves the problem; now watch reservation-confirm lag and oversells.

Third-party tags inflate checkout TTFB

GTM, FB pixel, an A/B-test SDK, a session-replay tag, a fraud-scoring beacon — all fire on the checkout page, none on your latency dashboard. Test the rendered page, not just the API: a checkout-init returning in 400ms but blocking on six third-party scripts is still a 4-second checkout. Strip tags one at a time between runs and watch p95 move.

Cart cache poisoning

The /cart endpoint behind Cloudflare or Fastly is a classic foot-gun: if the cache key omits the session cookie, one shopper's cart gets served to the next. Verify under load — VUs with unique session cookies on the same path should never see another VU's line items. Same trap on Shopify storefronts with custom edge logic and Magento Varnish varying on the wrong header.

Don't test against live PSPs

Stripe Elements, Adyen, Braintree each add one or two round-trips between checkout-init and order-confirm. Pointing tests at live PSPs burns rate limits and flags the account. Mock at production-equivalent latency (Stripe p95 ~250ms, Adyen ~400ms) and inject 0.5-2% failure to exercise retry paths. Verify order-create is idempotent: a duplicate key returns the existing order, not a second one. Charging twice is worse than not charging.

What drops legitimate carts

Fraud-rule timeouts that fail-closed instead of fail-open, gift-card balance lookups against a slow legacy service, Shopify cart-token reuse caps 429ing under burst, queue-it rooms releasing more than the origin absorbs. All surface as "checkout error rate spiked" with no clean stack trace. Tag each failed VU with the subsystem it died in.

Latency targets that mean something

• add-to-cart p95 < 800ms — abandonment climbs measurably beyond this
• checkout-init p99 < 2s — form interactive before shopper second-guesses
• payment-redirect TTFB < 600ms — gateway hop before PSP redirect
• order-confirm p99 < 3s — incl. PSP and inventory commit

Track per-step. A 4s order-confirm is fine if 3s are PSP; a fire if 3s are your code.

How to run it

Template ships in JMeter and k6 modes. Run from LoadFocus across the 26+ cloud regions — Sydney-to-us-east-1 latency is the real shopper experience. Thousands of VUs ramped in 5-minute steps so DB pools and autoscalers settle. Wire into CI (Jenkins, GitHub Actions, CircleCI) and fail builds on p99 regression vs baseline. Run it before the marketing email, not after.