Zum Hauptinhalt springen

Transactional Outbox

Einleitung​

Transactional Outbox löst das Atomaritätsproblem zwischen:

  • Datenbank-Commit
  • Event-Publikation

ohne verteilte Transaktionen (2PC).

Die Fachänderung und der Outbox-Eintrag passieren in derselben lokalen Transaktion.
Ein separater Relayer veröffentlicht die Events anschließend zuverlässig.

Ziel:

Keine verlorenen Events – trotz verteilter Systeme.

Einordnung

Transactional Outbox ist ein Zuverlässigkeits-Pattern für asynchrone Integration.

Es ist die robuste Ausprägung des allgemeinen Outbox-Patterns.

Typische Einsatzfelder:

  • Microservices mit Database-per-Service
  • Event-Driven Architecture
  • Saga-Koordination
  • CQRS / Read-Model-Projektionen

Grundprinzip

Kernaussage:

  • Domain-Write und Event-Erzeugung sind atomar
  • Publish erfolgt asynchron
  • Delivery ist mindestens einmal garantiert

Zentrale Eigenschaften

1️⃣ Gleicher Transaktionskontext​

Domain-Änderung + Outbox-Insert:

  • erfolgen im selben DB-Commit
  • sind damit atomar konsistent

Kein „DB erfolgreich, Event verloren“-Szenario.

2️⃣ At-Least-Once Delivery​

Das Pattern garantiert:

  • mindestens einmalige Zustellung

Es garantiert nicht:

  • Exactly-once

Daher Pflicht:

  • Idempotente Consumer
  • Eindeutige Event-IDs

3️⃣ Relay-Varianten​

🟢 Polling-Relay​

  • Periodisches Lesen der Outbox
  • Einfach zu implementieren
  • Gut verständlich

🟡 CDC-basiertes Relay​

  • Streaming aus DB-Log (z. B. Debezium)
  • Niedrige Latenz
  • Weniger Polling-Overhead

🔵 Log-Tailing​

  • Direktes Lesen des Write-Ahead-Logs
  • Hohe Effizienz
  • Infrastrukturintensiver

4️⃣ Monitoring-Anforderungen​

Wichtige Metriken:

  • Relay-Lag
  • Unverarbeitete Events
  • Dead Letter Queue
  • Publish-Fehler

Ohne Observability wird Outbox unsichtbar kritisch.

Vorteile

  • Keine verteilten Transaktionen
  • Konsistente Kopplung von State und Event
  • Stabil bei Broker-Ausfällen
  • Grundlage für Saga und CQRS

Risiken / typische Fallstricke

1️⃣ Fehlende Idempotenz​

Ohne idempotente Verarbeitung:

  • doppelte Buchungen
  • doppelte Reservierungen
  • Seiteneffekte

2️⃣ Relay-Lag​

Verzögerungen erzeugen:

  • temporäre Inkonsistenzen
  • Prozessverzögerungen

Eventual Consistency ist inhärent.

3️⃣ Outbox-Wachstum​

Ohne Cleanup:

  • Tabelle wächst unkontrolliert
  • Performance leidet

Retention-Strategie ist notwendig.

4️⃣ Verwechslung mit Messaging-Garantie​

Transactional Outbox:

  • garantiert keine End-to-End-Konsistenz
  • ersetzt kein durchdachtes Prozessmodell

Sie löst nur das Atomaritätsproblem.

Wann sinnvoll?

  • Events sind fachlich kritisch
  • Services sind entkoppelt
  • Database-per-Service im Einsatz
  • Saga oder Read-Projektionen notwendig

Wann unnötig?

  • Monolith ohne Messaging
  • Best-Effort-Events ausreichend
  • Kein Event-Broker im Einsatz

Strategische Perspektive

Transactional Outbox ist:

  • kein Business-Pattern
  • kein Performance-Pattern
  • kein Architektur-Statement

Es ist ein Integrations-Sicherheitsnetz.

Es verschiebt Komplexität von:

  • verteilten Transaktionen

zu:

  • Idempotenz
  • Monitoring
  • Messaging-Betrieb

Fazit

Transactional Outbox sorgt dafür, dass:

„Was gespeichert wurde, wird auch publiziert.“

Sie garantiert:

  • At-least-once Delivery
  • Keine verlorenen Events

Sie erfordert:

  • Idempotente Consumer
  • Monitoring
  • Betriebsdisziplin