---
title: "Warum der Checkout bei 10 % Serverlast ausfällt"
description: "Server im Leerlauf, Checkout nicht erreichbar. Lock-Contention, Cache-Stampedes, synchrone Payment-Calls: Ausfallmuster, gegen die Autoscaling nicht hilft."
author: "Luboš Zápotočný"
published: "2026-06-04"
language: "de"
canonical: "https://zapolu.com/de/blog/warum-der-checkout-im-sale-zusammenbricht/"
---

# Warum der Checkout bei 10 % Serverlast ausfällt

Es ist einer der am schwersten einzuordnenden Incidents für ein
E-Commerce-Team. Die Kampagne geht live, der Checkout läuft in
Timeouts, und die Dashboards zeigen unauffällige Werte: CPU bei
10 %, Speicher normal, reichlich freie Kapazität. Die naheliegende
Reaktion ist, Server zu ergänzen. Die neuen Server laufen ebenfalls
im Leerlauf, und der Checkout ist weiterhin nicht erreichbar.

Die Verwirrung kommt von einem falschen mentalen Modell. Last hat
zwei Komponenten: Arbeit und *Warten*. Ihre Server verbringen die
Zeit in Warteschlangen, und Warteschlangen tauchen auf keinem
CPU-Graphen auf.

## Die häufigsten Ursachen

**Lock-Contention in der Datenbank.** Der Checkout ist die Stelle,
an der der Shop aufhört zu lesen und anfängt zu schreiben: Bestand
reservieren, Bestellung anlegen, Adresse speichern. Diese Writes
serialisieren sich auf Row Locks, und Kampagnen-Traffic
konzentriert sich auf dieselben wenigen Zeilen. Hundert Kunden, die
während derselben Kampagne den Checkout durchlaufen, serialisieren
sich auf denselben heißen Zeilen: den Zählern der
Bestellnummernsequenz, den Bestell- und Warenkorbtabellen, dem
Bestand, der gerade reserviert wird. Jede Transaktion hält ihre
Locks, während sie auf andere Arbeit wartet. Der Durchsatz
kollabiert, während die CPU kaum etwas zu tun hat. Auf Magento hat
das eine bekannte Signatur: die Lock-Wait- und Deadlock-Meldungen,
die am Morgen nach dem Sale die Logs füllen.

**Cache-Stampedes.** Ein heißer Cache-Eintrag, etwa die
Kategorieseite, auf die jede Anzeige zeigt, läuft mitten im Peak
ab. Jeder Request, der den Eintrag jetzt nicht mehr vorfindet,
regeneriert die Seite gleichzeitig und belastet die Datenbank mit
identischen teuren Queries. Der Cache, der den Shop schnell gemacht
hat, wird zur Ursache des Ausfalls, und zwar nach einem Zeitplan,
den seine eigene TTL vorgibt.

**Synchrone Drittanbieter-Calls im Checkout-Pfad.** Versandkosten,
Zahlungsautorisierung, Steuerberechnung, ein Anti-Fraud-Check:
jeweils ein Netzwerkaufruf in das System von jemand anderem, während
Ihr Worker eine Connection und oft eine Datenbanktransaktion hält.
Wird ein Anbieter unter derselben Kampagnenlast von 200 ms auf 10
Sekunden langsam, wartet nach und nach jeder Worker in diesem
Aufruf.
Ob Ihr Shop ausfällt, hängt jetzt an einem Anbieter, auf den Sie
keinen Einfluss haben.

**Erschöpfte Worker und Connections.** Die drei Probleme oben teilen
sich einen Verstärker: Worker, die warten, belegen trotzdem ihren
Slot und ihre Datenbank-Connection. PHP-FPM-Prozesse, dimensioniert
für gewöhnliche Wochentagslast, füllen sich mit blockierten Requests,
neue Requests erhalten weder einen Worker noch eine Connection,
und der Ausfall erfasst jede Seite, die noch einen PHP-Worker braucht,
so wenig Arbeit diese Seite auch macht.

Keines der vier Probleme ist ein Hardware-Problem, weshalb
Autoscaling Sie nicht rettet: Neue Instanzen stellen sich in
dieselbe Schlange vor denselben Row Lock hinter demselben langsamen
Anbieter. Zusätzliche Kapazität erhöht nur die Zahl der wartenden
Instanzen.

## Wie Sie es frühzeitig erkennen

Für die Diagnose zählt weniger die *Auslastung* als die *Zeit*: Wohin
gehen die Millisekunden eines Checkout-Requests, in Arbeit oder in
Warten auf Locks, Caches und Drittanbieter-APIs? Distributed
Traces beantworten das direkt; ein Slow-Query-Log plus die
Lock-Wait-Zähler der Datenbank beantworten es günstig. Wenn Sie vor
der nächsten Kampagne nur einen einzigen Graphen ergänzen, nehmen
Sie Lock-Waits.

Die Fixes folgen aus der Diagnose, und die meisten sind
unspektakulär: Timeouts auf jedem Drittanbieter-Call und gecachte
Fallbacks überall dort, wo eine veraltete Antwort unschädlich ist (eine
leicht veraltete Versandkostenauskunft schadet nicht, eine
Zahlungsautorisierung muss dagegen live erfolgen), Stampede-Schutz, damit ein
Prozess den heißen Key neu baut, während die anderen den alten
Stand ausliefern, die Verlagerung nicht essenzieller Writes aus der
Transaktion in eine Queue, und die Reservierung des Bestands so spät
im Funnel, wie es das Geschäft erlaubt, statt ihn schon ab dem
Warenkorb zu halten. Welche davon für Ihren
Shop zählen, ist eine empirische Frage: die Sorte, die ein
[Performance-Audit](/de/services/performance-audit/) mit Ihren
Traces beantwortet statt mit Vermutungen, und die
Sorte, die unsere [DevOps-Arbeit](/de/services/devops/) anschließend
dauerhaft macht.

Hinter fast allen Kampagnen-Ausfällen steckt am Ende Concurrency,
nicht fehlende Kapazität. Prüfen Sie deshalb zuerst einen Trace,
bevor Sie zusätzliche Server beschaffen.