Updated July 2026. Refreshed for current microservices best practices.
The Distributed Transaction Problem
In a monolith, a single database transaction can update orders, inventory, and payments atomically. In microservices, each service has its own database. Two-phase commit (2PC) across services hurts availability and performance — the Saga pattern is the standard alternative.
What Is a Saga?
A saga is a sequence of local transactions. Each step commits independently. If a step fails, compensating transactions undo previous steps in reverse order. Example: CreateOrder → ReserveInventory → ChargePayment. If payment fails, release inventory and cancel order.
Choreography vs Orchestration
Choreography: services react to each other’s events with no central coordinator. Simple for 2–3 steps; hard to debug at scale.
Orchestration: a Saga Orchestrator service sends commands and tracks state. Better visibility and error handling for complex flows.
Kafka-Based Choreography Example
- Order Service publishes
OrderCreated - Inventory Service consumes, reserves stock, publishes
InventoryReservedorInventoryFailed - Payment Service consumes, charges card, publishes
PaymentCompletedorPaymentFailed - On failure, compensating events trigger rollbacks
Design Rules
- Every forward action needs a compensating action.
- Compensations must be idempotent.
- Store saga state (pending, completed, failed) for recovery.
- Use timeouts and dead-letter queues for stuck sagas.
Related: Outbox Pattern · CQRS with Kafka
Want live microservices classes? Join Alkademy for instructor-led microservices architecture courses with hands-on projects.
Go deeper with the book: Practical Microservices Design Using CQRS and Event Sourcing by Kindson Munonye.
Kindson Munonye is a software engineer and technical author specializing in microservices, CQRS, event sourcing, and distributed systems. He publishes free step-by-step tutorials and live classes on Alkademy.