Zum Hauptinhalt springen

Datenkonsistenz – Saga, Outbox, Idempotenz

Ausgangslage​

In einer Microservice-Architektur existieren keine verteilten ACID-Transaktionen über mehrere Services.

Klassische 2-Phase-Commit-Ansätze sind:

  • teuer
  • fragil
  • schwer skalierbar
  • operativ riskant

Stattdessen gilt:

Jeder Service besitzt lokale Transaktionen.
Konsistenz entsteht durch Event-Koordination.

Das führt zu Eventual Consistency statt sofortiger globaler Konsistenz.

Kernmuster

1️⃣ Saga – Fachliche Prozesskoordination​

Eine Saga beschreibt einen verteilten Geschäftsprozess, der aus mehreren lokalen Transaktionen besteht.

Es gibt zwei Varianten:

Saga – Orchestration​

Ein zentraler Orchestrator steuert den Ablauf.

Eigenschaften:

  • klare Ablaufsteuerung
  • gute Übersicht
  • zentrale Logik

Risiko: Orchestrator wird zu einem „Mini-Monolith“.

Saga – Choreography​

Services reagieren auf Events ohne zentrale Steuerung.

Eigenschaften:

  • hohe Dezentralität
  • weniger zentrale Abhängigkeit

Risiko: Prozessfluss wird schwer nachvollziehbar („Event-Spaghetti“).

2️⃣ Outbox Pattern – Robuste Event-Publikation​

Problem:

Wenn DB-Commit erfolgreich ist, aber Event-Publish fehlschlägt → Inkonsistenz.

Lösung:

Event wird in derselben lokalen Transaktion gespeichert.

Kernaussage:

  • State + Event werden atomar gespeichert
  • Event wird asynchron publiziert
  • Kein Verlust bei Crash zwischen DB und Broker

Outbox ist ein Infrastrukturmuster, kein Fachmuster.

3️⃣ Idempotenz – Schutz gegen Duplikate​

In verteilten Systemen gilt:

Messages können mehrfach zugestellt werden.

Consumer müssen deshalb:

  • Event-ID speichern
  • Verarbeitung erkennen
  • Mehrfachverarbeitung vermeiden

Typische Strategien:

  • Idempotency-Key
  • Deduplication-Table
  • UPSERT statt INSERT
  • State-basierte Verarbeitung

Ohne Idempotenz sind Retry-Strategien gefährlich.

Zusammenspiel der Muster

In reifen Systemen werden die Muster kombiniert:

  • Saga koordiniert fachliche Prozesse
  • Outbox sichert Event-Zuverlässigkeit
  • Idempotenz schützt vor Duplikaten

Erst das Zusammenspiel ergibt robuste Event-Konsistenz.

Mindestregeln für produktive Systeme

  • Events haben stabile IDs.
  • Events sind versioniert.
  • Consumer sind idempotent.
  • Retry mit Backoff ist definiert.
  • Dead Letter Queue ist vorhanden.
  • Events sind nachvollziehbar (Tracing / Correlation ID).
  • Kompensationslogik ist explizit definiert (Saga).

Typische Fehler

  • Event wird direkt nach DB-Commit publiziert (ohne Outbox)
  • Keine Event-Versionierung
  • Consumer vertrauen auf „exactly once“
  • Kompensation wird vergessen
  • Geschäftslogik wird implizit in Event-Handlern versteckt

Architekturelle Realität

Eventual Consistency ist kein Kompromiss – sie ist die Konsequenz verteilter Autonomie.

Microservices ohne Saga/Outbox/Idempotenz sind:

  • operativ fragil
  • schwer testbar
  • riskant bei Last und Fehlern

Robuste Datenkonsistenz ist kein Detail, sondern ein Architektur-Kernmerkmal.