Das Transactional Outbox-Muster löst das Dual-Write-Problem in verteilten Systemen: Schreibt eine Anwendung Fachdaten in die Datenbank und soll gleichzeitig ein Ereignis an einen Message Broker senden, sind das zwei getrennte Schreibvorgänge — einer kann fehlschlagen, die Systeme laufen auseinander. Die Outbox macht beide Schreibvorgänge atomar.
Funktionsweise
In derselben Datenbanktransaktion, die den Fachdatensatz ändert, wird das auszulösende Ereignis in eine zusätzliche Outbox-Tabelle geschrieben. Ein Relay-Prozess liest die Tabelle regelmäßig aus und veröffentlicht die Ereignisse an den Broker (z.B. Kafka). Danach markiert er die Einträge als verarbeitet. Verbreitet sind zwei Relay-Varianten:
- Polling Relay: Der Prozess fragt die Outbox-Tabelle in kurzen Abständen ab.
- Change Data Capture (CDC): Werkzeuge wie Debezium beobachten das Datenbank-Log und publizieren Änderungen direkt — auch für Replikations-Pipelines nutzbar.
Vorteile
- Keine verteilte Transaktion: Aufwändiges Zwei-Phasen-Commit (2PC) zwischen Datenbank und Broker entfällt.
- Garantierte Zustellung: Solange der Eintrag in der Outbox steht, wird das Ereignis irgendwann publiziert (at-least-once).
- Einfach zu überwachen: Die Outbox-Tabelle zeigt direkt, welche Ereignisse noch ausstehen.
Herausforderungen
- Idempotenz: Wegen at-least-once-Zustellung müssen Konsumenten doppelte Ereignisse tolerieren.
- Zusätzliche Infrastruktur: Outbox-Tabelle plus Relay (Polling oder CDC) müssen betrieben und überwacht werden.
Das Muster ist ein Baustein von Event-Sourcing- und CQRS-Architekturen in verteilten Systemen: Ereignisse wie „Auftrag erstellt“ verlassen den Dienst zuverlässig über die Outbox, statt die Datenbank mit dem Broker zu koppeln.
Verwandte Grundlagen: Kafka-Befehle, Verteilte Systeme, Eventual Consistency, Change Data Capture, Debezium.