When to Trust Saga Choreography Over Orchestration

The problem: coordinating long‑running, multi‑service transactions

In a microservice architecture a single business operation often spans several bounded contexts – order creation, payment, inventory, shipping, and so on. Each step may involve its own database transaction and can take minutes or hours to complete. The classic two‑phase commit does not scale across autonomous services, so developers turn to the Saga pattern. The pattern splits the overall transaction into a series of local actions, each paired with a compensating action that can undo its effects if something later fails.

Two implementation styles exist:

• Orchestrated sagas – a central coordinator (orchestrator) drives the workflow, invoking services via commands and listening for replies.
• Choreographed sagas – services react to domain events, publishing the next event when their local work succeeds.

Both achieve eventual consistency, but they differ dramatically in scalability, coupling, and operational complexity. The rest of this article explains when the decentralized, event‑driven choreography makes sense, how it impacts consistency models, and what API patterns you need to adopt.

---

Solution approach: how saga choreography works

1. Local transaction – a service performs its work and commits to its own database.
2. Event emission – on success the service publishes a domain event (e.g., OrderCreated).
3. Event subscription – any service that cares about that event consumes it, runs its own local transaction, and emits the next event (e.g., PaymentProcessed).
4. Compensation – if a step fails, the service emits a failure event (PaymentFailed). Other services that have already acted must listen for that failure and run their compensating actions (refund, release stock, cancel shipment).

Because there is no central coordinator, each service owns the part of the workflow that belongs to its bounded context. Adding a new participant is as simple as subscribing to an existing event and publishing a new one; existing services do not need to change.

API patterns that emerge

Pattern	Description	Example
Event‑carried state transfer	The event payload carries just enough data for downstream services to act without a synchronous call.	OrderCreated { orderId, customerId, total }
Idempotent event handlers	Handlers must be safe to run multiple times because at‑least‑once delivery is common in distributed logs.	Store processed eventId in a table and skip duplicates.
Correlation IDs	Every saga instance gets a unique identifier that is attached to every event, enabling tracing and debugging.	X‑Saga‑Id: 123e4567‑e89b‑12d3‑a456‑426614174000
Compensation contracts	For each success event there is a corresponding failure event that downstream services must understand.	PaymentProcessed ↔ PaymentFailed

---

Trade‑offs to consider

1. Scalability vs. observability

Scalability – Because each service processes events independently, the system can scale horizontally by adding more consumer instances. No single node becomes a bottleneck, and the failure of one consumer does not halt the entire saga.

Observability – The flip side is that there is no single source of truth for saga state. To reconstruct the workflow you need a centralized event store (e.g., EventStoreDB) or a log‑aggregation platform like Kafka Connect + Elasticsearch. Correlation IDs let you query the store for all events belonging to a saga, but the state is reactive – you only see what has already happened.

Rule of thumb: Use choreography only when you already have mature event streaming and tracing (OpenTelemetry, Jaeger, Zipkin) in place.

2. Consistency model

Both choreography and orchestration are eventually consistent; they do not provide atomicity across services. However, choreography pushes the consistency burden onto each service:

• Local ACID – each service guarantees its own transaction.
• Global consistency – achieved by the ordered flow of events. If an event is lost or reordered, the saga can stall.

To mitigate this you often need idempotent consumers and exactly‑once semantics provided by the underlying broker (Kafka with idempotent producers, Pulsar, or NATS JetStream). Without those guarantees, you risk duplicate compensations or orphaned resources.

3. Error handling and compensation complexity

In an orchestrated saga the orchestrator knows the full execution graph and can drive compensations in reverse order. In choreography each service must be aware of all failure events that could affect it. This leads to:

• Distributed compensation logic – every service implements its own rollback and retries.
• Higher verification cost – you need integration tests that simulate failure at every step and assert that the whole system reaches a clean state.

If your domain has simple, independent steps (e.g., “reserve stock → charge card → ship”), choreography is manageable. When you need conditional branches, loops, or complex business rules, the compensation matrix explodes and orchestration becomes safer.

4. Team autonomy vs. coordination overhead

Choreography shines when different teams own different services and want to avoid a shared orchestrator codebase that becomes a coordination hotspot. The contract is the event schema, which can evolve via backward‑compatible versioning (Protobuf, Avro, JSON Schema). However, the downside is implicit coupling – a change to an event shape can break downstream services if they are not updated in lockstep.

---

When to pick choreography

Situation	Why choreography fits
Few participants (2‑3 services)	The event graph stays simple, making monitoring tolerable.
Linear flow with straightforward compensation	No branching logic, so each service only needs to handle one success and one failure event.
Mature event streaming (Kafka, Pulsar) with built‑in replay and exactly‑once	Guarantees that events are not lost and can be reprocessed for recovery.
Independent teams that own bounded contexts	Teams can evolve their service without a central orchestrator pulling them together.
Long‑running processes where a central orchestrator would become a single point of failure	Each step can run for minutes/hours without keeping a live connection to a coordinator.

If you find yourself adding more than three participants, needing conditional routing, or lacking a reliable event store, start with an orchestrated saga (e.g., using Temporal.io or Camunda) and migrate later if the operational burden of choreography becomes justified.

---

Practical checklist for production‑ready saga choreography

1. Event schema registry – enforce versioned contracts (Confluent Schema Registry, Apicurio).
2. Correlation ID propagation – include a saga ID in every message header.
3. Idempotent consumers – store processed event IDs; design handlers to be repeatable.
4. Centralized log store – ship all events to Elasticsearch or ClickHouse for ad‑hoc queries.
5. Distributed tracing – instrument producers and consumers with OpenTelemetry spans linked by the saga ID.
6. Compensation test matrix – for each success event, write a failure test that triggers the corresponding compensating path.
7. Alerting on gaps – set up a watchdog that watches for missing expected events within a timeout window.

---

Closing thoughts

Saga choreography offers a compelling path to high scalability and team autonomy, but it demands a mature event‑driven foundation and disciplined engineering practices. Treat the event stream as both the glue and the source of truth; without reliable storage and tracing, you’ll spend more time hunting for missing events than delivering value.

For most critical business processes, start with an orchestrated saga to get the compensation logic right, then evaluate whether the added operational overhead of choreography is justified as the system grows.

---

Further reading

• Event Collaboration: Choreography vs Orchestration – Martin Fowler’s classic comparison.
• Saga Orchestration Pattern (Temporal) – practical guide to orchestrated sagas.
• Event‑Carried State Transfer Pattern – how to design payloads for choreography.
• OpenTelemetry for Distributed Tracing – instrumenting your saga events.