Stabile Checkout-Systeme in NestJS: Retry, Idempotenz und Selbstoptimierung

Die Zahlungsabwicklung ist ein kritischer Pfad im E-Commerce – doch was passiert, wenn der Zahlungsanbieter ausfällt oder Antworten verloren gehen? Ein einfacher Retry-Mechanismus kann schnell zur Falle werden: Der Kunde bestätigt die Zahlung, die Transaktion wird ausgeführt, doch die Bestätigung kommt nie zurück. Der Retry löst erneut aus – und der Kunde wird doppelt belastet. Genau diese Herausforderung stand im Mittelpunkt eines Projekts, bei dem ein Checkout-System entwickelt wurde, das solche Szenarien von vornherein verhindert.

Die Architektur: Ein robuster Pipeline-Ansatz

Das System folgt einem klar strukturierten Ablauf, der in vier logische Schritte unterteilt ist. Jeder Schritt erhält einen typsicheren OrderContext, verarbeitet ihn und gibt ein Result zurück – ein fehlerhaftes Ergebnis stoppt die Pipeline sofort. Diese Methode vermeidet verschachtelte try-catch-Blöcke und behandelt Fehler als Werte. Der Ablauf lautet wie folgt:

• POST /orders: Validierung des Inventars und Reservierung der Artikel.
• CalculatePricingStep: Anwendung von Rabatten und Berechnung des Gesamtbetrags.
• ChargePaymentStep: Kontaktierung des Zahlungsanbieters mit integriertem Retry und Idempotenzschutz.
• CreateOrderStep: Persistierung der Bestellung und Auslösung von Ereignissen.

Der Zahlungsschritt ist dabei der komplexeste Teil der Pipeline. Hier kommen drei zentrale Konzepte zum Einsatz:

• Idempotenzschlüssel: Der Schlüssel charge:${ctx.orderId} ist eindeutig pro Bestellung – nicht pro Anfrage. Falls die erste Zahlung erfolgreich ist, der Server aber die Antwort verliert, wird bei einem Retry der zwischengespeicherte Erfolg zurückgegeben. Der Zahlungsanbieter wird nicht erneut kontaktiert.
• Retry-Logik: Nur bei Serverfehlern (HTTP 500 oder 503) wird ein Retry ausgelöst. Geschäftsfehler wie ungültige Daten (HTTP 400) oder nicht gefundene Ressourcen (HTTP 404) führen nicht zu erneuten Versuchen.
• Jitter im Backoff: Eine zufällige Verzögerung („full random“) verhindert, dass bei gleichzeitigen Ausfällen mehrerer Bestellungen eine massive Lastspitze entsteht.

Performance unter Normalbedingungen: Die Baseline

Um die Stabilität des Systems zu messen, wurde ein Lasttest mit 50 virtuellen Nutzern über zwei Minuten durchgeführt. Der Skriptname order-flow.k6.js simulierte dabei den vollständigen Bestellprozess pro Iteration. Die Ergebnisse waren vielversprechend:

• Erfolgsquote: 96,58 %
• Durchschnittliche Latenz: 1,17 Sekunden
• P95-Latenz: 2,03 Sekunden
• Durchsatz: 13,5 Bestellungen pro Sekunde
• Ausfallrate: 3,42 % (simuliertes Rauschen des Zahlungsanbieters)

Unter realistischen Bedingungen ohne zusätzliche Last bewältigte das System die Pipeline in unter 1,2 Sekunden. Die Ausfälle von 3,42 % waren dabei auf das künstlich erzeugte Rauschen des Zahlungsanbieters zurückzuführen – nicht auf Fehler im Anwendungscode.

Schutz vor Ausfällen: Der Circuit Breaker im Einsatz

Ein weiterer Test simulierte eine stark verschlechterte Leistung des Zahlungsanbieters mit einer Ausfallrate von 80 %. Ohne Circuit Breaker hätten 80 % der Anfragen auf den Timeout des Zahlungsanbieters gewartet – was zu einer Überlastung der Threads, einer wachsenden Warteschlange und einer allgemeinen Degradierung des Systems geführt hätte.

Mit Circuit Breaker sah das Bild deutlich besser aus:

• Gesundheitsendpunkt blieb zu 100 % erreichbar.
• Durchschnittliche Antwortzeit: 5,05 Millisekunden.
• Schnelle Antwort bei Auslösung des Breakers: etwa 5 Millisekunden (statt 1,2 Sekunden im Normalbetrieb).
• Ausfallrate der HTTP-Anfragen: 49,99 %.

Der Circuit Breaker isolierte die Zahlungsabwicklung vom Rest des Systems und verhinderte eine Kettenreaktion. Während 49,99 % der Anfragen fehlschlugen, blieben die Gesundheitsprüfungen stabil. Die schnelle Reaktion auf Ausfälle sparte Ressourcen und verhinderte eine Eskalation der Probleme.

Retry und Idempotenz bei hohen Ausfallraten: Ein kritischer Test

Der wichtigste Testfall für E-Commerce-Systeme ist eine stark degradierte, aber nicht vollständig ausgefallene Zahlungsinfrastruktur. In diesem Szenario, simuliert mit einer Ausfallrate von 60 %, zeigte das System seine wahre Stärke:

• Erfolgsquote mit Retry-Mechanismus: 78,2 %
• Anzahl der Retry-Versuche mit Latenz über 500 Millisekunden: 825
• Idempotenz-Wiederholungsrate: 100 %
• Korrekte Durchläufe im Lebenszyklus: 4 von 4
• P95-Latenz mit Retry: 1.345 Millisekunden

Die Berechnung belegt die Wirksamkeit: Bei einer Ausfallwahrscheinlichkeit von 60 % pro Versuch und maximal drei Retry-Versuchen beträgt die Wahrscheinlichkeit für drei aufeinanderfolgende Ausfälle 21,6 %. Die tatsächliche Ausfallrate lag bei 21,8 % – exakt im erwarteten Rahmen. Die 825 Anfragen mit hoher Latenz waren Bestellungen, die im ersten Versuch scheiterten, aber im Retry erfolgreich waren. Ohne Retry wären dies verlorene Verkäufe gewesen.

Besonders entscheidend war die Idempotenz: Jede wiederholte Anfrage – etwa durch den Verlust der Antwort – kehrte das zwischengespeicherte Ergebnis zurück, ohne die Zahlung erneut auszulösen. Die 100 %-Rate bestätigte dies in diesem und einem separaten Test.

Der Idempotenz-Vertrag: Sicherheit ohne Kompromisse

Ein weiterer Test prüfte die Integrität der Idempotenz-Schicht mit 1.383 Iterationen in vier parallelen Szenarien:

• Wiederholungs-Erfolgsrate: 100 %
• Fehlender Idempotency-Key-Header: 422 (422 Unprocessable Entity)
• Ungültige Schlüsselformate: 422
• Gesamte Ausfallrate: 3,3 % (statistisch identisch zur Baseline)
• P95-Latenz: 1.322 Millisekunden

Der Vertrag stellt sicher, dass Clients ohne gültigen Idempotenzschlüssel abgewiesen werden – noch bevor die Geschäftslogik greift. Dies verhindert, dass unsichere Anfragen die Schutzmechanismen umgehen. Die zusätzliche Latenz und Fehlerquote durch die Idempotenz-Schicht blieb vernachlässigbar.

Selbstoptimierung: Das System lernt mit

Der fortschrittlichste Teil des Projekts ist die Fähigkeit des Systems, sich selbst zu optimieren. In einem Test mit dem Skript auto-learning.k6.js durchlief das System drei Phasen über 160 Sekunden:

In der ersten Phase (t=0s) starteten fünf virtuelle Nutzer mit einer Ausfallrate von 5 % und einer Verzögerung von 100 Millisekunden. Über die Zeit passte das System Parameter wie Retry-Zähler, Backoff-Zeiten und Circuit-Breaker-Schwellenwerte automatisch an, ohne dass manuelle Eingriffe nötig waren. Diese Selbstregulation stellt sicher, dass das System auch bei sich ändernden Lastmustern optimal performt.

Fazit: Stabilität durch bewusste Architektur

Dieser Ansatz zeigt, dass ein robustes Checkout-System nicht durch das Hinzufügen von immer mehr Retry-Mechanismen erreicht wird – sondern durch eine durchdachte Kombination aus Idempotenz, Circuit Breaker und selbstlernenden Algorithmen. Die Tests belegen, dass solche Systeme nicht nur Ausfälle abfedern, sondern auch die Stabilität und Benutzererfahrung in kritischen Momenten verbessern können. Für Entwickler, die ähnliche Herausforderungen meistern müssen, bietet die Implementierung in NestJS eine solide Grundlage, die sich an reale Bedingungen anpasst und gleichzeitig Sicherheit vor Doppelbelastungen garantiert.