Test de Charge Checkout : Modèle Black Friday

Le checkout BFCM tombe en panne différemment du reste de l'année. La ligne d'inventaire que vous décrémentiez à 5 RPS deadlocke à 500 ; le tag tiers qui ajoutait 80ms en octobre en ajoute 2s quand son CDN s'enrhume. Ce template charge le funnel tel qu'une journée de flash sale le façonne — mutation de panier, init de paiement, création de commande — pas des hits de pages isolées.

Décrément d'inventaire sous concurrence

Le pattern hot row catalog_product_entity + cataloginventory_stock_item de Magento s'effondre quand 2 000 paniers frappent le même SKU dans une fenêtre de 30 secondes. Même histoire sur les stacks qui enrobent un SELECT ... FOR UPDATE autour de la réservation de stock. Martelez un petit set de SKUs (10-50 produits) pour faire surgir la contention — une distribution uniforme sur un catalogue cache le deadlock. La réservation async déplace le problème ; maintenant surveillez le lag de reservation-confirm et les oversells.

Les tags tiers gonflent le TTFB du checkout

GTM, FB pixel, un SDK d'A/B-test, un tag de session-replay, un beacon de fraud-scoring — tous tirent sur la page de checkout, aucun sur votre dashboard de latence. Testez la page rendue, pas seulement l'API : un checkout-init qui répond en 400ms mais bloque sur six scripts tiers est toujours un checkout de 4 secondes. Retirez les tags un par un entre les runs et regardez bouger le p95.

Cache poisoning sur le panier

L'endpoint /cart derrière Cloudflare ou Fastly est un foot-gun classique : si la cache key omet le cookie de session, le panier d'un shopper est servi au suivant. Vérifiez sous charge — des VUs avec des cookies de session uniques sur le même path ne doivent jamais voir les line items d'un autre VU. Même piège sur les storefronts Shopify avec logique edge custom et Magento Varnish qui varie sur le mauvais header.

Ne testez pas contre les PSPs live

Stripe Elements, Adyen, Braintree ajoutent chacun un ou deux aller-retours entre checkout-init et order-confirm. Pointer les tests sur les PSPs live brûle les rate limits et flag le compte. Mockez à latence équivalente prod (Stripe p95 ~250ms, Adyen ~400ms) et injectez 0,5 à 2% d'échec pour exercer les chemins de retry. Vérifiez que order-create est idempotent : une clé dupliquée renvoie la commande existante, pas une seconde. Facturer deux fois est pire que ne pas facturer.

Ce qui fait tomber les paniers légitimes

Timeouts de règles de fraude qui fail-closed au lieu de fail-open, lookups de solde gift-card contre un legacy lent, caps de réutilisation de cart-token Shopify qui 429 sous burst, salles queue-it qui relâchent plus que l'origin n'absorbe. Tout ça remonte comme "le taux d'erreur checkout a spiké" sans stack trace propre. Taguez chaque VU échoué avec le sous-système où il est mort.

Cibles de latence qui veulent dire quelque chose

• add-to-cart p95 < 800ms — l'abandon grimpe de façon mesurable au-delà
• checkout-init p99 < 2s — formulaire interactif avant que le shopper ne doute
• payment-redirect TTFB < 600ms — saut gateway avant la redirection PSP
• order-confirm p99 < 3s — incl. PSP et commit d'inventaire

Suivez par étape. Un order-confirm de 4s est acceptable si 3s sont du PSP ; c'est un incendie si 3s sont votre code.

Comment l'exécuter

Le template existe en modes JMeter et k6. Lancez depuis LoadFocus sur les 26+ régions cloud — la latence Sydney-vers-us-east-1 est la vraie expérience shopper. Des milliers de VUs rampés par paliers de 5 minutes pour que les pools DB et les autoscalers se stabilisent. Branchez dans la CI (Jenkins, GitHub Actions, CircleCI) et faites échouer les builds sur régression p99 vs baseline. Lancez-le avant l'email marketing, pas après.