Understanding SAGA Distributed Transactions: Choreography vs Orchestration

1. Distributed Transaction Problem Description

In an e‑commerce system, placing an order requires calls to the order service, inventory service, and logistics service, each with its own database. Because the operations span multiple databases, a single database transaction cannot be used, yet the business logic demands atomicity across all writes.

If the order and inventory services succeed but the logistics service fails, the previous writes must be rolled back to keep data consistent. This is the essence of the distributed transaction problem.

SAGA is a long‑standing solution (over 20 years) that addresses this problem via two main strategies: Choreography and Orchestration.

2. SAGA – Choreography Strategy

Choreography treats each service as a dancer that follows a pre‑defined sequence of actions. The workflow proceeds as follows:

Order service writes its data and records the overall order status (e.g., "order placed").

Order service publishes an "order created" event; inventory service listens.

Inventory service receives the event, writes its data, and publishes an "inventory updated" event.

Order service listens to the inventory event and updates the order status to "ready to ship".

Logistics service listens to the inventory event, writes its data, and publishes a "logistics processed" event.

Order service receives the logistics event and updates the order status to "shipped".

Event‑driven coordination ensures all services stay consistent.

When an exception occurs (e.g., logistics service fails), the handling flow is:

Logistics service publishes a "logistics error" event.

Order and inventory services listen to this event and receive the error notification.

Order service executes its rollback logic.

Inventory service executes its rollback logic.

This strategy is simple to implement but can become complex as the number of services and event subscriptions grows.

3. SAGA – Orchestration Strategy

Orchestration introduces a central coordinator (the "orchestrator") that directs each participant service, similar to a conductor leading an orchestra.

Typical normal flow:

Order service writes its data.

Order service reports completion to the orchestrator.

Orchestrator instructs the inventory service to execute.

Inventory service writes its data and reports back.

Orchestrator instructs the order service to update the order status.

Orchestrator instructs the logistics service to execute.

If a service (e.g., logistics) encounters an error, it reports to the orchestrator, which then sends rollback commands to the order and inventory services.

The orchestrator’s behavior is typically implemented via a state machine, providing clear overall control but adding complexity due to the extra component.

4. Summary

Choreography relies on an event‑driven model where each service reacts to events it cares about; Orchestration uses a central state‑machine‑based coordinator to drive the entire saga. Currently, Orchestration is the dominant approach, and Alibaba's Seata framework implements it.

Happy Learning!