Saga Choreography Pattern

Overview

Saga Choreography is a design pattern for managing distributed transactions where there is no central coordinator. Instead, each service participates in the saga by listening for events, performing its local transaction, and emitting a new event for the next service in the chain. Compensation is also event-driven -- failure events cascade back through the same event bus, triggering each service to undo its work.

This approach is a natural fit for event-driven microservice architectures where services communicate through a message broker such as Apache Kafka, RabbitMQ, or Amazon EventBridge. Each service only knows about the events it consumes and produces, with no awareness of the overall saga flow.

Compare this with the Saga Orchestration pattern, where a central Orchestrator issues commands and controls the workflow. Both patterns solve the same problem -- distributed transactions without 2PC -- but make fundamentally different tradeoffs.

Architecture

Event Bus (Kafka)

The backbone of the choreography. All saga events flow through Kafka topics. Each service has its own topic (e.g., orders.events, payments.events, inventory.events, shipping.events). Services publish events after completing their local transaction and subscribe to topics from upstream services.

Service Chain

Services form an implicit chain through their event subscriptions:

Client -> Order Service -> [orders.events]
                            -> Payment Service -> [payments.events]
                                                   -> Inventory Service -> [inventory.events]
                                                                           -> Shipping Service -> [shipping.events]
                                                                                                   -> Order Service (finalize)

Each service in the chain:

1. Consumes an event from the previous service's topic
2. Executes its local transaction against its own database
3. Publishes a result event (success or failure) to its own topic

Compensating Event Flow

On failure, events flow in reverse through the bus:

Inventory Service emits InventoryFailed -> [inventory.events]
  -> Payment Service consumes, refunds, emits PaymentRefunded -> [payments.events]
    -> Order Service consumes, cancels order

Each service independently decides how to react to failure events from downstream services. There is no central component coordinating the compensation.

Per-Service Databases

Each service owns its data store. There are no shared databases or distributed locks. Consistency is achieved through the saga event chain rather than through database-level transactions.

Key Concepts

Event-Driven Coordination

Services react to events rather than receiving commands. The Order Service does not tell the Payment Service to charge -- it simply emits an OrderCreated event. The Payment Service decides on its own to charge when it sees that event. This keeps services decoupled at the API level.

Decentralized Compensation

Each service is responsible for its own compensation logic. The Payment Service knows that when it sees an InventoryFailed event, it should refund the charge and emit PaymentRefunded. The Order Service knows that when it sees PaymentRefunded, it should cancel the order. No central component dictates these reactions.

No Single Point of Failure

Because there is no Orchestrator, there is no single component whose failure halts all sagas. If one service goes down, events queue up in Kafka and are processed when the service recovers. The event bus provides durability and buffering.

Implicit Workflow

The saga workflow is defined implicitly by the event subscriptions across services. There is no single place that shows the full flow. To understand the complete saga, you must trace which service listens to which topic and what events it produces. This is a key tradeoff of choreography.

Trade-offs

Advantages

• No single point of failure -- the saga continues as long as the event bus and participant services are running
• Loose coupling -- services only depend on event schemas, not on a central coordinator
• Independent deployability -- adding a new service means subscribing to existing topics without modifying other services
• Scalability -- each service scales independently; Kafka partitions enable parallel processing

Disadvantages

• Hard to debug -- there is no central log showing the saga state; tracing requires correlating events across multiple topics and services
• No central visibility -- operators cannot query a single place to see where a saga stands
• Risk of event storms -- poorly designed event schemas or retry logic can cause cascading events
• Circular dependencies -- complex flows can create cycles in event subscriptions that are difficult to detect and reason about
• Difficult to change flow order -- reordering steps means changing event subscriptions across multiple services

When to Use

Saga Choreography works well for:

• Simple, linear flows with a small number of participants (2-4 services)
• Highly decoupled architectures where teams own services end-to-end
• Systems already built on event-driven infrastructure (Kafka, EventBridge)
• Scenarios where avoiding a single point of failure is critical

Consider Saga Orchestration instead when:

• The workflow has many steps or conditional branching
• You need central monitoring and operational visibility
• Compensation logic is complex and depends on the combination of completed steps
• Multiple teams need to understand the full transaction flow

Scenarios

1. Happy Path -- Events flow successfully through the entire chain: OrderCreated triggers PaymentCharged, which triggers InventoryReserved, which triggers ShippingScheduled. The final ShippingScheduled event flows back to the Order Service, which marks the order as confirmed.
2. Failure Path -- Order and payment succeed, but inventory reservation fails due to insufficient stock. The Inventory Service emits InventoryFailed, which the Payment Service consumes to issue a refund (PaymentRefunded), which the Order Service consumes to cancel the order. Compensating events cascade back through the event bus without any central coordinator directing them.