Why Saga Beats 2PC for Distributed Business Consistency

Why 2PC Doesn’t Work in Micro‑service Scenarios

When a business operation spans several bounded contexts (BCs) – e.g., salary disbursement that involves attendance, payroll calculation, finance approval, bank transfer, tax reporting, and notification – the naive idea is to use a distributed transaction (XA/2PC). In practice 2PC fails because it blocks synchronously, creates a single‑point‑of‑failure coordinator, and cannot roll back external actions such as bank transfers or SMS notifications.

What Saga Is

Saga, first proposed in a 1987 paper, breaks a long transaction into a chain of local ACID transactions, each followed by a compensating action that undoes its effect if a later step fails. The article illustrates this with a salary‑disbursement example showing six steps (T1‑T6) and their corresponding compensations (C1‑C6).

Key observations:

Saga does not guarantee atomicity – intermediate steps may be visible, so the business must tolerate temporary inconsistency.

Compensation is not rollback – it is a new business action that neutralises the previous effect (e.g., marking a failed bank transfer for manual review).

Each step must record its state so that a crashed saga can resume from the correct point.

Two Main Implementation Styles

Orchestration (Central Coordinator)

A central orchestrator knows the whole workflow, invokes each BC in order, and triggers compensations on failure. The article provides a Java orchestrator example that persists a SagaInstance, iterates over steps, and calls the appropriate facades. Pros and cons are listed:

Pros : clear end‑to‑end view, easy debugging, suitable for long flows with external systems.

Cons : the orchestrator can become a God class and a single point of change.

Choreography (Event‑driven)

Each BC publishes a domain event after completing its local transaction; other BCs listen to the event and continue the flow. The article shows Spring event‑listener handlers for attendance lock, payroll calculation, and compensation on failure. Advantages and drawbacks are:

Pros : loose coupling, easy to add or remove steps without touching a central component.

Cons : the overall process is invisible, compensation chains become tangled, and circular dependencies can arise.

Choosing Between Orchestration and Choreography

The article provides a decision matrix. Use orchestration when the workflow has many steps (>4), involves external systems, requires visible state for stakeholders, or demands strong governance (e.g., salary disbursement, order fulfillment). Use choreography for short, simple flows with few participants and a need for high extensibility (e.g., user registration, simple order‑notification pipelines). Mixed approaches are also common.

Designing Compensation Logic

Idempotency : compensation must produce the same result on repeated calls; implement deduplication via a compensation‑record table.

Business‑level reversal : you may not be able to revert a bank transfer, but you can mark it for manual reconciliation.

Escalation to humans : when automatic compensation fails (e.g., bank timeout), create a manual task and alert operators.

Intermediate states : enrich the read model (e.g., PaySlipStatus) with statuses like CALCULATED, APPROVED, PAYING, PAYMENT_FAILED.

Observability : log structured events with sagaId, cycle, and current step to enable end‑to‑end tracing.

State Machine – The Core of Saga Execution

Regardless of style, a saga instance is a state machine that persists current step, succeeded steps, compensated steps, and payload. The article shows a minimal SQL schema for saga_instance and a scheduled recovery job that picks up stalled sagas and resumes them.

Framework Options

Spring Statemachine – lightweight, integrates with Spring, fits orchestration.

Seata Saga – Alibaba’s distributed‑transaction framework with visual console.

Axon Framework – event‑driven, treats saga as a first‑class citizen.

Temporal / Cadence – heavyweight workflow engine with built‑in persistence, retries, and compensation.

For small projects a hand‑rolled state table and simple orchestrator suffice; for complex, high‑governance scenarios adopt a dedicated framework.

Conclusion

2PC/XA is impractical in micro‑service environments due to blocking, single‑point‑of‑failure, and lack of rollback for external calls.

Saga provides eventual consistency via a chain of local ACID transactions and compensations.

Choose orchestration for long, complex, externally‑bound flows; choose choreography for short, loosely‑coupled interactions.

Compensation must be idempotent, business‑oriented, and escalated when automatic handling fails.

Persist saga state and run periodic recovery to guarantee progress.

Use existing state‑machine frameworks for large‑scale needs; simple tables are enough for most cases.