E-Commerce Checkout Lasttest: Black Friday

BFCM-Checkout fallt anders aus als der Rest des Jahres. Die Inventory-Zeile, die Sie bei 5 RPS dekrementiert haben, deadlockt bei 500; das Drittanbieter-Tag, das im Oktober 80ms drauflegte, legt 2s drauf, wenn dessen CDN schwachelt. Dieses Template belastet den Funnel so, wie ein Flash-Sale-Tag ihn formt - Cart-Mutation, Payment-Init, Order-Create - nicht als isolierte Page-Hits.

Inventory-Dekrement unter Concurrency

Magentos Hot-Row-Muster aus catalog_product_entity + cataloginventory_stock_item bricht zusammen, wenn 2.000 Warenkorbe innerhalb von 30 Sekunden dieselbe SKU treffen. Dieselbe Geschichte bei Stacks, die SELECT ... FOR UPDATE um die Bestandsreservierung wickeln. Hammern Sie auf einen kleinen SKU-Set (10-50 Produkte), damit die Contention sichtbar wird - eine gleichmassige Verteilung uber einen Katalog versteckt den Deadlock. Asynchrone Reservierung verlagert das Problem; jetzt beobachten Sie Reservation-Confirm-Lag und Oversells.

Drittanbieter-Tags blasen Checkout-TTFB auf

GTM, FB pixel, ein A/B-Test-SDK, ein Session-Replay-Tag, ein Fraud-Scoring-Beacon - alle feuern auf der Checkout-Seite, keiner steht auf Ihrem Latenz-Dashboard. Testen Sie die gerenderte Seite, nicht nur die API: Ein Checkout-Init, der in 400ms zuruckkommt, aber auf sechs Drittanbieter-Skripten blockiert, ist immer noch ein 4-Sekunden-Checkout. Ziehen Sie Tags zwischen den Runs einzeln raus und beobachten Sie, wie sich p95 bewegt.

Cart-Cache-Poisoning

Der /cart-Endpoint hinter Cloudflare oder Fastly ist ein klassischer Eigentor-Pfad: Wenn der Cache-Key das Session-Cookie weglasst, wird der Warenkorb des einen Kaufers dem nachsten serviert. Verifizieren Sie unter Last - VUs mit eindeutigen Session-Cookies auf demselben Pfad sollten niemals die Line-Items eines anderen VU sehen. Dieselbe Falle bei Shopify-Storefronts mit Custom-Edge-Logic und bei Magento-Varnish, das nach dem falschen Header variiert.

Nicht gegen Live-PSPs testen

Stripe Elements, Adyen, Braintree legen jeweils ein oder zwei Round-Trips zwischen Checkout-Init und Order-Confirm. Tests auf Live-PSPs zu richten verbrennt Rate-Limits und flaggt den Account. Mocken Sie mit produktionsaquivalenter Latenz (Stripe p95 ~250ms, Adyen ~400ms) und injizieren Sie 0,5-2% Fehler, um Retry-Pfade zu belasten. Verifizieren Sie, dass Order-Create idempotent ist: Ein doppelter Key liefert die existierende Bestellung zuruck, nicht eine zweite. Zweimal belasten ist schlimmer als nicht belasten.

Was legitime Warenkorbe killt

Fraud-Rule-Timeouts, die fail-closed statt fail-open laufen, Gift-Card-Balance-Lookups gegen einen langsamen Legacy-Service, Shopify-Cart-Token-Reuse-Caps, die unter Burst 429en, queue-it-Raume, die mehr freigeben als der Origin absorbiert. Alles taucht als "Checkout-Error-Rate hat Spike" ohne sauberen Stack-Trace auf. Taggen Sie jeden gescheiterten VU mit dem Subsystem, in dem er gestorben ist.

Latenzziele, die etwas bedeuten

• add-to-cart p95 < 800ms - Abandonment steigt daruber messbar
• checkout-init p99 < 2s - Formular interaktiv, bevor der Kaufer ins Grubeln kommt
• payment-redirect TTFB < 600ms - Gateway-Hop vor dem PSP-Redirect
• order-confirm p99 < 3s - inkl. PSP und Inventory-Commit

Tracken Sie pro Schritt. Ein 4s-Order-Confirm ist ok, wenn 3s davon PSP sind; ein Brand, wenn 3s davon Ihr Code sind.

Wie man es fahrt

Das Template kommt in JMeter- und k6-Modi. Fahren Sie aus LoadFocus uber die 26+ Cloud-Regionen - Sydney-zu-us-east-1-Latenz ist die echte Kauferfahrung. Tausende von VUs in 5-Minuten-Schritten gerampt, damit DB-Pools und Autoscaler einrasten. Verdrahten Sie in CI (Jenkins, GitHub Actions, CircleCI) und brechen Sie Builds bei p99-Regression gegen Baseline ab. Fahren Sie es vor der Marketing-E-Mail, nicht danach.