Warum Eventual Consistency verteilten Transaktionen überlegen ist (Warum Eventual Consistency Verteilten Transaktionen Ueberlegen Ist)

Über diese acht Teile hinweg sind wir von der Provider-Abstraktion zu semantischen Events, Fehlertaxonomie, Retry-Algorithmen, Leases, Abgleich und der Heilung von Orphan Charges gegangen. Die Frage darunter kann jetzt direkt gestellt werden: Warum diese ganze Komplexität ertragen? Warum nicht einfach PSP, Bestellung und Finanzdatensatz in eine Transaktion packen und alle diese Probleme auf einmal lösen?

Die Antwort ist einfach und endgültig: Der PSP kann niemals an Ihrer Transaktion teilnehmen.

Was 2PC erfordert
  Coordinator ←→ Teilnehmer 1 (Order DB)
  Coordinator ←→ Teilnehmer 2 (Finance DB)
  Coordinator ←→ Teilnehmer 3 (PSP??)

Die tatsächliche Welt des PSP
  Führt Ihr Transaktionsprotokoll nicht aus
  Lebt an seiner eigenen Netzwerkgrenze, mit eigenem Konsistenzmodell
  Kennt Ihr 'Prepare'- oder 'Commit'-Signal nicht

Wo die Begriffe zuerst auftauchen

📦 Two-Phase Commit (2PC)
Ein Protokoll, das mehrere Teilnehmer dazu bringt, eine Transaktion gemeinsam vollständig zu übernehmen oder vollständig zurückzurollen.

📦 Saga
Ein Muster, das einen Workflow, der nicht in eine einzige ACID-Transaktion passt, in eine Folge lokaler Operationen mit jeweils eigener Kompensation aufteilt.

📦 Eventual Consistency
Ein Modell, das akzeptiert, dass das System nicht in jedem Moment konsistent ist, aber innerhalb einer begrenzten Zeit zu einem konsistenten Zustand konvergiert.

📦 Abgleich als Backstop
Das letzte Sicherheitsnetz, das den wahren Zustand wiederherstellt, wenn der Kompensationsschritt einer Saga fehlschlägt oder ausgelassen wird.

2PC erfordert, dass alle Teilnehmer denselben Coordinator, dasselbe Protokoll und dieselben Annahmen über Netzwerkzuverlässigkeit teilen. Der PSP akzeptiert keine dieser Annahmen — er ist ein System außerhalb Ihrer Kontrolle, mit eigenem SLA, eigener API und eigenem Fehlermodell.

Warum der PSP nicht an einer 2PC teilnehmen kann

Selbst wenn Sie einem PSP eine 'Prepare'-Anfrage senden wollten, gefolgt von 'Commit' oder 'Rollback' — er unterstützt dieses zweiphasige Protokoll nicht, weil die Karte selbst, das Banknetzwerk und die Betrugsprüfung ihre Entscheidung meist schon in einer einzigen Phase getroffen haben. Die API eines PSP sagt nicht 'ich entscheide später, warte'; sie sagt 'ja' oder 'nein'. Schlägt die zweite Phase (Commit) auf Ihrer Seite fehl, gibt es kein Konzept, dass der PSP seine Operation zurückrollt — es gibt nur eine separate Erstattungsanfrage, die selbst ein asynchroner, nicht garantierter Vorgang ist.

Die Welt, die 2PC voraussetzt
  Prepare → alle Teilnehmer sagen 'bereit' → Commit → alle akzeptieren gleichzeitig

Die reale Welt des PSP
  Charge-Anfrage → der PSP entscheidet sofort → das Ergebnis ist endgültig
  Rückgängig machen wollen → eine separate Refund-Anfrage, ein separater asynchroner Prozess

Saga: eine Kette lokaler Entscheidungen

Der Ansatz, der 2PC ersetzt, lässt jedes System seine eigene lokale Transaktion ausführen und erst per Event zum nächsten Schritt übergehen. Schlägt ein Schritt fehl, werden vorherige Schritte nicht zurückgerollt — jeder wird durch seine eigene kompensierende Aktion korrigiert.

Charge beim PSP erfolgreich
  → Bestellung erzeugen (lokale Transaktion)
  → Finanzdatensatz erzeugen (lokale Transaktion)

Schlägt der Finanzdatensatz fehl
  → Kompensation für die Bestellung: stornieren
  → Kompensation für den PSP: Refund-Anfrage senden

Das ist die direkte Konsequenz der Tatsache aus einem früheren Teil dieser Serie, dass 'Capture einfach, Finalisierung schwer' ist: Die Schwierigkeit der Finalisierung ist genau die Schwierigkeit, die Kompensationsschritte einer Saga zu entwerfen.

Abgleich: das Sicherheitsnetz der Saga

Eine Saga garantiert nicht, dass ihre Kompensationsschritte immer laufen — auch die Kompensationsanfrage kann fehlschlagen, das Netzwerk kann abbrechen, ein Worker kann abstürzen. Genau deshalb ist alles, was in den vorherigen Teilen aufgebaut wurde (Leases, der Abgleich-Worker, die Heilung von Orphan Charges), die zweite Schicht, die aufräumt, wenn die Saga allein nicht reicht.

Saga (der primäre Pfad)
  → bewegt sich Schritt für Schritt, jeder Schritt besitzt seine eigene Kompensation

Abgleich (das sekundäre Sicherheitsnetz)
  → durchsucht periodisch, was die Saga ausgelassen oder nicht kompensiert hat, und korrigiert es

Die eigentlichen Kosten von Eventual Consistency: ein Fenster, keine Falschheit

Eventual Consistency bedeutet nicht 'die Daten können eine Zeit lang falsch sein'; es bedeutet 'die Daten können eine Zeit lang unvollständig oder veraltet sein, aber diese Zeit wird gemessen und begrenzt'. Dieses Fenster muss auf Produktseite sichtbar sein: Wie viele Sekunden oder Minuten können vergehen, bis der Bestellstatus nach der Zahlung sichtbar ist? Das ist kein technisches Detail, sondern eine Produktentscheidung — und es ist der Kern dessen, was diese Serie von Anfang an vertreten hat: In einem verteilten Zahlungssystem ist perfekte, augenblickliche Konsistenz eine Illusion; das eigentliche Ziel ist ein kurzes, gemessenes, beobachtbares Fenster der Inkonsistenz.

Ansatz	Garantie	Tatsächlich erreichbar
2PC (inklusive PSP)	Sofortige, vollständige Konsistenz	Nein — der PSP kann nicht teilnehmen
Saga + Kompensation	Schrittweiser Fortschritt, rückwirkende Korrektur	Ja
Saga + Abgleich	Begrenztes, gemessenes Inkonsistenzfenster	Ja — das von dieser Serie vertretene Modell

Häufig verwechselte Unterschiede

❌ Eventual Consistency = ein inkonsistentes System
✓ Eventual Consistency = Konvergenz zur Konsistenz innerhalb eines begrenzten, gemessenen Fensters

❌ Eine Saga ist nur eine einfachere Version von 2PC
✓ Eine Saga ist ein völlig anderes Modell: kein Rollback, nur Kompensation

❌ Abgleich zu benötigen zeigt einen Entwurfsfehler der Saga
✓ Abgleich ist ein permanentes, in verteilten Systemen inhärentes Sicherheitsnetz, kein Mangel der Saga

2PC vs. Saga + Abgleich

Kriterium	2PC	Saga + Abgleich
Teilnahme des PSP	erforderlich, aber unmöglich	nicht erforderlich
Sperrdauer	über alle Teilnehmer gehalten	keine
Widerstandsfähigkeit gegen Teilausfälle	niedrig	hoch
Operative Komplexität	in der Theorie niedrig, in der Praxis unmöglich	hoch, aber real

Checkliste zur Bewertung dieses Modells

1. Kann jede externe Abhängigkeit im System (inklusive PSP) am selben Transaktionsprotokoll teilnehmen? Wenn nicht, ist 2PC keine Option.
2. Hat jeder Saga-Schritt eine klar definierte kompensierende Aktion?
3. Was passiert, wenn eine kompensierende Aktion fehlschlägt — verschwindet sie stillschweigend, oder fängt der Abgleich sie auf?
4. Wird das Eventual-Consistency-Fenster gemessen und mit dem Produktteam geteilt?
5. Zielt das System auf 'innerhalb kurzer, begrenzter Zeit konsistent' statt auf die Illusion 'jederzeit konsistent'?

Was aus diesen acht Teilen bleiben soll

1. Der PSP ist ein externes System und kann niemals an Ihrem Transaktionsprotokoll teilnehmen — genau deshalb ist 2PC eine Falle.
2. Eine Saga ist die realistische Alternative, bei der jeder Schritt seine eigene lokale Transaktion ausführt und seine eigene Kompensation besitzt.
3. Abgleich ist kein Mangel einer Saga, sondern ein permanentes, in verteilten Systemen inhärentes Sicherheitsnetz.
4. Eventual Consistency ist keine Falschheit — es ist ein gemessenes, beobachtbares Konvergenzfenster.

Was ein verteiltes Zahlungssystem braucht, ist nicht perfekte, augenblickliche Konsistenz — es ist, genau zu wissen, wie lange die Inkonsistenz dauern wird.

Das schließt den achtteiligen Bogen, der mit der Provider-Abstraktion begann: SDK-Leckage verhindern, semantische Events erzeugen, Fehler richtig klassifizieren, diszipliniert wiederholen, Arbeit sicher mit Leases besitzen, Drift durch Abgleich erkennen und Orphan Charges mit Beweisen heilen — all das dient derselben einen Tatsache: Ein verteiltes Zahlungssystem strebt nicht nach Perfektion, sondern nach kontrollierter, beobachtbarer Inkonsistenz.