Bis Lektion 4.12.3 hat jeder Dienst seine Daten, und jede Transaktion endet an seiner Grenze. Ein Büro, das an einer Ausschreibung teilnehmen will, braucht aber beides: Der Dienst Ausschreibungen soll die Ausschreibung für das Büro reservieren, damit niemand im Büro sie ein zweites Mal bearbeitet, und die Kladde soll den Entwurf eines Angebots anlegen. Früher wären das zwei Zeilen in einer Transaktion gewesen. Jetzt sind es zwei Datenbanken. Diese Lektion baut daraus eine Saga.
Eine Saga statt einer Transaktion
Microsofts Azure Architecture Center beschreibt das Saga-Muster so: Eine Saga ist eine Folge lokaler Transaktionen. Jede läuft in einem Dienst, ändert dessen Datenbank und stößt den nächsten Schritt an. Scheitert ein Schritt, machen Ausgleichstransaktionen (compensating transactions) rückgängig, was die Schritte davor getan haben. Eine verteilte Transaktion über zwei Datenbanken, etwa mit Zwei-Phasen-Commit, passt nicht zu Diensten, die unabhängig ausgeliefert und betrieben werden.
Der Leitfaden unterscheidet drei Arten von Schritten:
- Ausgleichbare Schritte (compensable): Sie lassen sich durch einen Schritt mit der umgekehrten Wirkung zurücknehmen. Die Reservierung ist so ein Schritt; ihr Ausgleich ist die Freigabe.
- Der Drehpunkt (pivot): der Punkt ohne Rückkehr. Ist er erreicht, wird nichts mehr ausgeglichen; was danach kommt, muss zu Ende laufen. Den Punkt kennen Sie aus Lektion 4.6.4. In der Teilnahme ist es das angelegte Angebot: Sobald eine Person daran arbeitet, nimmt die Saga es nicht mehr zurück.
- Wiederholbare Schritte (retryable): Sie kommen nach dem Drehpunkt, sind idempotent und werden so lange wiederholt, bis sie gelingen.
Eine Saga hat keine Isolation. Zwischen ihren Schritten sehen andere einen halben Zustand: eine Ausschreibung, die reserviert ist, aber noch kein Angebot hat. Der Leitfaden nennt dafür Gegenmittel; eines davon, die semantische Sperre, ist die Reservierung selbst. Sie sagt allen anderen: „Hieran wird gerade gearbeitet.“