Effectively-Once-Verarbeitung bei Zahlungen (Effectively Once Verarbeitung Bei Zahlungen)

Im vorherigen Teil haben wir gesehen, wie die Recovery-Pipeline mit Automatisierung zuerst arbeitet und evidenzbasierte Runbooks an Uniqueness-Wänden greifen. Dieser Teil geht in die Messaging-Garantien darunter — und in den verbreitetsten Irrtum der Branche: Exactly-once Delivery.

Broker-Anbieter versprechen 'Exactly-once Semantics'. Die Realität: In einem verteilten System kann die exakt einmalige Verarbeitung einer Nachricht physisch nie garantiert werden. Netzwerke brechen ab, Worker stürzen ab, Broker liefern erneut. Die Frage ist nicht 'wie oft kam die Nachricht an' — sondern wie oft trat das Geschäftsergebnis ein.

Exactly-once Messaging → unmöglich (at-least-once + failure = duplicate)
Effectively-once Ergebnis → erreichbar (defense in depth)

Wo die Begriffe zuerst auftauchen

📦 At-Least-Once Delivery
Eine Nachricht kommt mindestens einmal an; bei Netzwerkfehler kann sie erneut gesendet werden.

📦 Effectively-Once
Auch wenn eine Nachricht mehrfach verarbeitet wird, tritt das Geschäftsergebnis (Charge, Refund, Order) nur einmal ein.

📦 Defense in Depth
Mehrere unabhängige Schutzschichten statt Vertrauen auf einen einzigen Mechanismus.

📦 Idempotent Consumer
Ein Consumer, der bei zweiter Zustellung dasselbe Ergebnis ohne Nebenwirkungen erzeugt.

Exactly-once Messaging ist kein Broker-Feature; Effectively-Once ist Systemdesign.

Warum Exactly-Once eine Lüge ist

Ein Worker empfängt eine Nachricht, verarbeitet sie, sendet ein Acknowledgment — aber das Ack geht im Netzwerk verloren. Der Broker liefert erneut. Der Worker verarbeitet nochmal. Das ist inhärent in At-Least-Once Delivery; egal wie sehr ein Broker 'Exactly-once' behauptet, Duplikate auf Consumer-Seite sind unvermeidlich.

Worker verarbeitet Nachricht → Ergebnis: Captured
Ack im Netzwerk verloren
Broker liefert erneut
Worker verarbeitet nochmal → Ergebnis: ??? (Doppelbelastungsrisiko)

Das Problem ist nicht, wie oft die Nachricht ankam — sondern was beim zweiten Mal passiert. Produziert die zweite Ankunft keine Nebenwirkung, haben Sie Effectively-Once erreicht.

Defense in Depth: eine Schicht reicht nicht

Ein effectively-once Geschäftsergebnis ist die Kombination ergänzender Schichten. Keine allein reicht; zusammen erzeugen sie 'eine mindestens einmal angekommene Nachricht wirkt höchstens einmal'.

Schicht 1: Idempotency Key (API)
  → zweite Charge-Anfrage mit demselben Key wird abgelehnt

Schicht 2: Consumer Dedup (Messaging)
  → dieselbe Message-ID wird nicht zweimal verarbeitet

Schicht 3: DB Uniqueness Constraint
  → zweite Zeile mit demselben Idempotency Key kann nicht geschrieben werden

Schicht 4: Outbox Pattern
  → Event wird nur zusammen mit Transaction Commit veröffentlicht

Schicht 5: Abgleich
  → korrigiert periodisch Drift, den Schichten 1–4 verpasst haben

Schlägt eine Schicht fehl, fängt eine andere. Wird der Idempotency Key übersprungen, fängt der Uniqueness Constraint; wird der Constraint umgangen, korrigiert der Abgleich.

Jede Schicht beantwortet eine andere Frage

Schicht	Frage	Schützt vor
Idempotency Key	Gleiche Absicht nochmal?	Doppelbelastung auf API-Ebene
Consumer Dedup	Gleiche Nachricht nochmal?	Doppelverarbeitung auf Messaging-Ebene
Uniqueness Constraint	Zweite Zeile mit gleichem Key?	Doppeldatensatz auf DB-Ebene
Outbox	Event vor Commit veröffentlicht?	Verlorenes oder vorzeitiges Event
Abgleich	Lokal vs PSP stimmt nicht?	Alles, was durchrutschte

Idempotenten Consumer schreiben

Die Regel für einen idempotenten Consumer: gleicher Input, gleicher Output; beim zweiten Aufruf keine Nebenwirkung.

PaymentCaptured Webhook (messageId=wh_991)
  → Dedup-Tabelle prüfen: wh_991 schon verarbeitet?
  → ja → skip (log: duplicate suppressed)
  → nein → finalisieren, in Dedup-Tabelle schreiben

Der Finalize-Schritt selbst muss idempotent sein: Ist die Zahlung bereits Captured, darf kein Event erneut veröffentlicht, keine Order neu erzeugt werden. Die Dedup-Tabelle schützt die Messaging-Schicht; die Terminal-Status-Prüfung schützt die Geschäftslogik.

Outbox: Event und State in derselben Transaktion

Das Outbox Pattern löst das Dilemma 'State aktualisiert, aber Event nicht veröffentlicht' oder 'Event veröffentlicht, aber State nicht aktualisiert'. Das Event wird zusammen mit der lokalen Transaktion in die Outbox-Tabelle geschrieben; ein separater Publisher liest die Outbox und sendet an den Broker.

BEGIN TRANSACTION
  UPDATE payment SET status=Captured
  INSERT INTO outbox (event=PaymentCaptured, paymentId=8812)
COMMIT
  → Publisher liest Outbox → sendet an Broker
  → Senden erfolgreich → Outbox-Zeile löschen

Outbox liefert kein Messaging-Exactly-Once — garantiert aber Konsistenz zwischen State und Event. Abgleich fängt, was aus der Outbox entweicht.

Häufig verwechselte Unterschiede

❌ Broker Exactly-Once = System Exactly-Once
✓ Broker Dedup + Consumer Idempotency + DB Constraint = Effectively-Once

❌ Idempotency Key reicht überall
✓ Idempotency Key schützt die API; Webhooks und Async-Worker brauchen eigene Schichten

❌ Effectively-Once = perfektes System
✓ Effectively-Once = Ergebnis einmal; Inkonsistenzfenster schließt via Abgleich

Delivery Guarantee vs Geschäftsergebnis

Garantie	Was sie verspricht	Für Zahlungen ausreichend
At-most-once	Nachricht einmal, kann verloren gehen	Nein — verlorene Zahlung
At-least-once	Mindestens einmal, kann duplizieren	Nein — allein
Exactly-once (Broker)	Theoretisch, bricht auf Consumer-Seite	Nein
Effectively-once (System)	Geschäftsergebnis einmal	Ja

Effectively-Once-Checkliste

1. Sind API-Charge-Anfragen durch Idempotency Keys geschützt?
2. Gibt es Message-ID-Dedup auf Webhook- und Async-Consumern?
3. Gibt es einen Uniqueness Constraint auf Idempotency Key in der Payment-Tabelle?
4. Sind State-Änderung und Event-Veröffentlichung via Outbox Pattern in derselben Transaktion?
5. Überspringt der Finalize-Handler ohne erneute Verarbeitung bei terminalen Status?
6. Scannt der Abgleich periodisch Drift, den Schichten 1–5 verpasst haben?

Was bleiben soll

1. Exactly-once Messaging ist eine Lüge; At-Least-Once + Failure macht Duplikate unvermeidlich.
2. Ein effectively-once Geschäftsergebnis ist durch Defense in Depth erreichbar — eine Schicht reicht nicht.
3. Jede Schutzschicht beantwortet eine andere Frage; alle müssen zusammenarbeiten.
4. Abgleich ist die letzte Schicht; er ersetzt die anderen nicht, er vervollständigt sie.

Auch wenn Ihr Broker Exactly-Once verspricht, sollte Ihr Zahlungssystem dem nicht glauben — es sollte effectively-once Geschäftsergebnisse durch Defense in Depth aufbauen.

Der nächste Teil synthetisiert diese 22-teilige Reise: eine Production-Payment-Engine-Design-Checkliste.