Saga Pattern

Run a business transaction that spans multiple services as a sequence of local transactions, each atomic in its own service and each paired with a compensating transaction that semantically reverses it if a later step fails. It trades isolation for service autonomy: concurrent sagas can observe each other's intermediate state.

Business operations that span multiple microservices (reserve inventory, charge payment, create shipment) cannot be wrapped in one ACID transaction. Without coordination, a partial failure leaves the system inconsistent with no defined recovery path.

A transaction spanning multiple services cannot be wrapped in one ACID transaction without 2PC, which is blocking and impractical across heterogeneous, independently owned services. A saga instead models the work as a sequence of local transactions T1, T2, ... Tn, each atomic within its own service. If step Tk fails, the saga runs compensating transactions C(k-1), C(k-2), ... C1 in reverse to undo the steps that already committed.

A saga gives ACD, not ACID. It provides atomicity in the sense that the sequence eventually either fully completes or is fully compensated, consistency, and durability, but it gives up isolation. That missing I is the whole design tension. Because each Ti commits on its own, there is no boundary hiding the half-finished saga from anyone else.

Lack of isolation and observable intermediate states. While a saga is mid-flight, its committed-but-not-yet-final steps are visible to concurrent transactions. Another saga can read state left by T1 before Tn runs or before compensation reverses it, which produces business-level anomalies: a dirty read of state that will be compensated away, or a lost update when two sagas touch the same record. The database will not prevent this, so the application must.

Countermeasures live in the application, not the engine. The common one is a semantic lock: a saga marks the records it is working on with an in-progress or pending flag, and other transactions treat a flagged record specially (wait, reject, or handle it as tentative) rather than acting on half-done state. Others include commutative updates, designing steps so their order does not change the result (increment and decrement rather than set), and reread-or-version checks that detect a concurrent modification before committing. These reintroduce, by hand, the isolation the saga gave up.

Choreography failure modes. In a choreographed saga each service publishes an event on completion and subscribes to others' events to know when to act; there is no coordinator, and the transaction emerges from the event flow. It is simple to deploy but the saga's state is implicit, scattered across topics, so understanding or debugging a stuck saga means correlating events across services, and cyclic event dependencies appear beyond a few steps. It suits sagas of 2 to 4 steps.

Orchestration failure modes. In an orchestrated saga a central orchestrator, usually a state machine persisted in PostgreSQL, commands each participant and issues compensations on failure. It gives one place to observe and audit saga state, which suits 5-plus steps and complex error handling, but the orchestrator is a single point of failure and potential bottleneck: it must persist its state durably and deliver commands at-least-once so a restart resumes in-flight sagas rather than losing them.

Compensation is not rollback. A committed step really happened and may have had external side effects (an email sent, a card charged). Compensation does not erase it; it issues a new forward transaction that semantically reverses it (a refund, not an un-charge). That compensation can itself fail, which needs a dead-letter path and manual intervention, and some effects cannot be reversed at all. Because delivery is at-least-once, every step and every compensation must be idempotent, or a redelivery will double-charge or double-allocate.