Microservices Saga Pattern

What this diagram shows

This diagram illustrates the Saga pattern for managing distributed transactions across microservices without a two-phase commit. A saga consists of a sequence of local transactions, each performed by a single service. When a step fails, compensating transactions are triggered in reverse order to undo completed work. The orchestrator coordinates the flow, an event bus carries state changes and compensation signals, and the outbox pattern ensures that events are written atomically with the service's local transaction, preventing event loss during failures.

Key components

• Saga Orchestrator — Coordinates the sequence of local transactions across services and triggers compensations on failure.
• Service A/B/C (Local Transaction) — Performs a single business operation within its own database and publishes events on success.
• Compensating Transaction — Rolls back a completed local transaction when a subsequent step fails, restoring the system to a consistent state.
• Outbox Table — Stores events atomically with the service's local transaction to ensure exactly-once publication to the event bus.
• Event Bus — Delivers events and compensation commands reliably between the orchestrator and services.
• State Store — Maintains the saga instance state, including current step, completed steps, and compensation history for recovery after crashes.

When to use it

Use the Saga pattern when you need ACID-like guarantees across microservices without relying on distributed locks or two-phase commit. Suitable for long-running transactions (order processing, payment flows) where services are owned by different teams or deployed independently. Ideal when consistency must eventually settle rather than be instantaneous, and when rollback costs are acceptable. Avoid if your transaction set is tiny or if services must share transactional boundaries.

Common mistakes

• Omitting the outbox pattern and publishing events outside the local transaction, risking event loss if the service crashes after the database write but before the message is sent.
• Forgetting to define and test compensating transactions for every saga step, leaving the system unable to recover from mid-sequence failures.
• Building an orchestrator that lacks durability and recovery logic, so that restarts lose track of saga state and either replay steps or abandon partial transactions.

Adapting it to your system

Identify your long-running business process and decompose it into steps, each owned by a single service. Define the local transaction and success event for each step. Then design a compensating transaction for each step that safely undoes its effects; document idempotency requirements so compensations can be retried. Implement the outbox pattern in each service: write the local data and an event row in one database transaction. Choose an event bus (Kafka, RabbitMQ, pub-sub) that your orchestrator can consume from reliably. Build the orchestrator as a state machine with persistent state storage so it can recover and resume after crashes. Test failure scenarios: inject faults at each step and verify compensation sequences execute correctly.