Wie implementiert man das Saga-Pattern zur Sicherstellung der Datenkonsistenz über verteilte Microservices in einem Order-Management-System?

Die Implementierung des Saga-Patterns erfolgt durch die Zerlegung einer globalen Transaktion in eine Sequenz lokaler Transaktionen. Jeder beteiligte Microservice führt seine lokale Transaktion aus und löst ein Ereignis aus, das die nächste lokale Transaktion im folgenden Service startet. Tritt ein Fehler auf, wird eine Kette von kompensierenden Transaktionen ausgelöst, um die bereits erfolgten Änderungen rückgängig zu machen und die Eventual Consistency wiederherzustellen.

Wir unterscheiden zwei primäre Koordinationsansätze:

Im Order-Management-System setzen wir den Ablauf typischerweise wie folgt auf:

1. Order Service: Erstellt die Bestellung (Status: PENDING).
2. Payment Service: Bucht den Betrag vom Kundenkonto ab.
3. Inventory Service: Reserviert die physischen Artikel im Lager.
4. Order Service: Setzt den Status auf COMPLETED.

Sollte der Inventory Service einen Fehler melden (z. B. Artikel nicht verfügbar), wird ein InventoryFailed-Event gesendet. Der Payment Service reagiert darauf mit einer Rückbuchung des Betrags, und der Order Service markiert die Bestellung als CANCELLED.

Die technische Umsetzung erfordert eine robuste Message-Infrastruktur (z. B. Apache Kafka oder RabbitMQ) und die Implementierung des Outbox-Patterns. Letzteres stellt sicher, dass Datenbank-Updates und das Versenden von Events atomar erfolgen, um Inkonsistenzen bei Systemausfällen zu vermeiden. Für die Optimierung dieser Datenflüsse und die Analyse der Event-Streams nutzen wir unsere Expertise im Bereich Data Engineering.

Die Wahl des Ansatzes hängt von der Anzahl der beteiligten Services und der Komplexität der Geschäftslogik ab. Bei komplexen Workflows führt die Choreografie oft zu einem unübersichtlichen Event-Netzwerk, bei dem der Gesamtzustand einer Bestellung nur schwer zu rekonstruieren ist.

Wir empfehlen für Order-Management-Systeme konsequent die Orchestrierung, da nur so die volle Kontrolle über den Transaktionsstatus gewahrt bleibt und die Fehlerbehandlung zentral definiert werden kann, anstatt sie in jedem einzelnen Service redundant und schwer wartbar zu implementieren.