Sagas: mehrstufige Workflows über mehrere Services mit Kompensation statt Rollback

Worum es geht

Die zitierte Pattern-Seite von microservices.io definiert eine Saga als eine Folge lokaler Transaktionen: Jede aktualisiert die Datenbank eines Services und veröffentlicht eine Nachricht oder ein Ereignis, das die nächste lokale Transaktion auslöst. Schlägt eine lokale Transaktion fehl, weil sie eine Geschäftsregel verletzt, führt die Saga Kompensationstransaktionen aus, die die Änderungen der vorangegangenen Schritte rückgängig machen. Die Koordination erfolgt entweder als Choreografie (jeder Service reagiert auf Ereignisse) oder als Orchestrierung (ein Orchestrator sagt den Beteiligten, was zu tun ist). Die Seite nennt die Nachteile: kein automatisches Rollback, da Kompensationen von Hand geschrieben werden, und keine Isolation, sodass gleichzeitig laufende Sagas gegenseitig ihre Zwischenzustände lesen können.

Das Azure Architecture Center (zitiert) ergänzt ein nützliches Vokabular: kompensierbare Transaktionen lassen sich rückgängig machen; eine Pivot-Transaktion ist der Punkt ohne Wiederkehr, ab dem die Saga vorwärts bis zum Abschluss laufen muss; wiederholbare Transaktionen folgen auf den Pivot und sind idempotent, damit die Saga immer abgeschlossen werden kann.

Warum es wichtig ist

Sobald Daten in mehreren Services liegen, kann «Bestellung anlegen, Lagerbestand reservieren, Karte belasten» keine einzelne Datenbanktransaktion mehr sein. Ohne eine explizite Saga sind die Fehlerpfade implizit: eine Belastung ohne Bestellung, für immer reservierter Lagerbestand.

So wird es angewendet

• Den Erfolgspfad als Liste von Schritten aufschreiben und neben jeden kompensierbaren Schritt seine Kompensation setzen. Hat ein Schritt keine sinnvolle Kompensation (eine versendete E-Mail, eine erfasste Zahlung), ist er der Pivot oder muss danach kommen.
• Die Schritte so ordnen, dass diejenigen, die am ehesten an Geschäftsregeln scheitern, zuerst kommen und der irreversible Schritt zuletzt.
• Jeden Schritt und jede Kompensation idempotent machen und über die Saga-ID schlüsseln, da Nachrichten mindestens einmal zugestellt werden.
• Den Saga-Zustand persistieren (welcher Schritt erfolgreich war), damit ein neu gestarteter Orchestrator fortsetzt statt neu zu starten; die auslösenden Ereignisse über ein Outbox-Muster veröffentlichen.
• Die Isolationslücke bewusst behandeln: Datensätze bis zum Abschluss der Saga als ausstehend markieren, und Leser sollen den ausstehenden Zustand entsprechend behandeln.
• Für jeden Schritt ein Timeout setzen und festlegen, was bei Ablauf geschieht (kompensieren oder an einen Menschen eskalieren).

Stolpersteine

Eine Kompensation ist eine neue Geschäftsaktion, kein Rollback: Eine Rückerstattung ist keine Rücknahme der Belastung, sie kann selbst fehlschlagen und muss wiederholt werden können. Die Azure-Seite beschreibt Choreografie als geeignet für einfache Workflows mit wenigen Services und weist darauf hin, dass der Ablauf mit zunehmender Schrittzahl unübersichtlich wird; ein Orchestrator mit einer sichtbaren Zustandsmaschine lässt sich bei längeren Sagas leichter betreiben. Sagas heben die Notwendigkeit nicht auf, dass der letzte Schritt bei Wiederholungen idempotent sein muss.