Das Saga-Pattern für verteilte Transaktionen
Lernen Sie, mit dem Saga-Pattern und den Ansätzen Choreografie und Orchestrierung die Datenkonsistenz über Microservices hinweg ohne verteilte Transaktionen zu wahren.
Das Saga-Pattern für verteilte Transaktionen ist eine kostenlose System Design Basics for Backend Developers-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des System Design Basics for Backend Developers-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der System Design Basics for Backend Developers-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
The Distributed Transaction Problem
In a monolith, one database transaction can update everything atomically. In microservices, each service owns its own database, so a single classic transaction across them is impractical.
How do you keep data consistent when an operation spans multiple services?
Why Not Two-Phase Commit?
Two-phase commit (2PC) can coordinate a distributed transaction, but it locks resources across services and blocks if the coordinator fails. It scales poorly and hurts availability — usually the wrong fit for microservices.
Enter the Saga
A Saga breaks a business transaction into a sequence of local transactions, one per service. Each step publishes an event or sends a command to trigger the next.
There is no global lock — consistency is achieved over time.
Compensating Transactions
If a later step fails, the saga cannot roll back like a database. Instead it runs compensating transactions that semantically undo the earlier steps.
- Order placed -> compensate by cancelling order
- Payment charged -> compensate by refunding
An Order Saga
Consider placing an order: reserve inventory, charge payment, schedule shipping. If payment fails, you compensate by releasing the inventory.
steps = ['reserve_inventory', 'charge_payment', 'schedule_shipping']
compensations = ['release_inventory', 'refund_payment', 'cancel_shipping']
done = []
for i, step in enumerate(steps):
ok = step != 'charge_payment'
if not ok:
print('FAILED at', step)
for j in reversed(range(len(done))):
print('compensate:', compensations[j])
break
done.append(step)
print('ok:', step)Choreography
In choreography, there is no central coordinator. Each service listens for events and reacts by doing its work and emitting the next event. It is decentralized and loosely coupled.
OrderCreated -> (Inventory) -> InventoryReserved
InventoryReserved -> (Payment) -> PaymentCharged
PaymentCharged -> (Shipping) -> OrderShippedChoreography Trade-offs
Choreography is simple for short flows but the overall logic is scattered across services. With many steps it becomes hard to understand and risks cyclic event dependencies.
Orchestration
In orchestration, a central orchestrator tells each service what to do and tracks progress. The workflow lives in one place, making complex sagas easier to reason about and monitor.
Orchestrator:
-> Inventory.reserve()
-> Payment.charge()
-> Shipping.schedule()
on failure -> run compensations in reverseIdempotency Is Mandatory
Messages can be delivered more than once, so every saga step and compensation must be idempotent. Use an idempotency key so re-processing the same message has no extra effect.
Eventual Consistency
Sagas give eventual consistency, not immediate. There is a window where the system is partially updated. Design the UI and business rules to tolerate this — for example, an order shown as PENDING until confirmed.
Choosing an Approach
Use choreography for simple flows with few participants, and orchestration when the workflow is complex or needs central visibility. Either way, make steps idempotent and define a compensation for every action.
Quick Check
Test your understanding of the Saga pattern.
Recap
You learned how microservices stay consistent without distributed transactions:
- Sagas chain local transactions with compensations for failures
- Choreography is decentralized; orchestration is centralized
- Steps must be idempotent against duplicate delivery
- The result is eventual consistency, which the design must tolerate
Lerne System Design Basics for Backend Developers mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 12
- Lektionen
- 48
Häufig gestellte Fragen
Ist die Lektion „Das Saga-Pattern für verteilte Transaktionen“ kostenlos?
Ja — der vollständige Text von „Das Saga-Pattern für verteilte Transaktionen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des System Design Basics for Backend Developers-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der System Design Basics for Backend Developers-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Das Saga-Pattern für verteilte Transaktionen“?
Lernen Sie, mit dem Saga-Pattern und den Ansätzen Choreografie und Orchestrierung die Datenkonsistenz über Microservices hinweg ohne verteilte Transaktionen zu wahren. Du übst System Design Basics for Backend Developers mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um System Design Basics for Backend Developers zu starten?
Keine Vorkenntnisse erforderlich. System Design Basics for Backend Developers auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Das Saga-Pattern für verteilte Transaktionen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser System Design Basics for Backend Developers-Lektion Code schreiben und ausführen?
Ja. Jede System Design Basics for Backend Developers-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Monolithen zerlegen
- Service Discovery und Registry
- Muster für die Kommunikation zwischen Services
- Das Saga-Pattern für verteilte Transaktionen