Saga vs Two-Phase Commit

2PC introduces a coordinator that owns the commit decision. Phase 1 (prepare): the coordinator asks every participant — flight, hotel, payment — to lock its resources and vote yes or no, without committing yet. Phase 2 (commit): only if every participant voted yes does the coordinator tell all of them to commit; if any voted no, or timed out, it tells all of them to abort. Every participant holds its lock for the entire round trip.

That lock is the mechanism and the cost. If the coordinator crashes after every participant has voted yes but before it sends the commit message, each participant is stuck: it cannot unilaterally commit (the coordinator might still abort) or abort (the coordinator might still commit), so it holds its lock until the coordinator recovers and tells it what happened. This is 2PC's well-documented blocking problem — a single coordinator failure can hold locks across three services indefinitely.

A saga replaces one distributed transaction with a sequence of independent local transactions, each committed immediately in its own service. Book the flight — done. Reserve the hotel — done. Charge the card — done. No cross-service lock is ever held; each step is final the moment it commits.

The trade is that a saga cannot roll back like a database transaction, because earlier steps already committed and other actions may have happened since. Instead, every step that can fail after an earlier step succeeded needs a compensating action: CancelFlight undoes BookFlight, ReleaseHotel undoes ReserveHotel. A compensation is a new business action recorded in its own right — a refunded charge, a released seat — not a magic undo of history.

A saga still needs something deciding what happens next after each step. Choreography does this with events: FlightBooked triggers the hotel service to reserve a room, HotelReserved triggers payment, and a failure event triggers whichever services need to compensate — no service owns the whole sequence. Orchestration puts a dedicated saga orchestrator in charge: it calls each service directly, tracks which steps have committed, and decides when to call compensating actions.

Choreography keeps services decoupled but scatters the booking's logic across every participant's event handlers — tracing "why did this booking fail" means reading code in three services. Orchestration centralizes that logic in one place, readable end to end, at the cost of a new component every saga step now depends on.

Trigger. Booking trip-903: the flight books, the hotel reserves, then the payment provider declines the card. Symptom. Without compensation, the customer now holds a flight and a hotel room they never paid for — and the hotel's inventory shows one fewer room than it actually has. Root mechanism. Each step committed as its own local transaction the instant it succeeded; there is no database transaction spanning all three to roll back.

Recovery. The orchestrator (or the payment-declined event, in choreography) triggers compensation in reverse order: ReleaseHotel(trip-903) first, then CancelFlight(trip-903). Both compensations are idempotent — replaying ReleaseHotel on an already-released room is a no-op, not a double-release. Verification: query flight and hotel inventory for trip-903 and confirm both show released; query payment for the decline record and confirm no partial charge exists. Prevention: run every saga step with a bounded timeout and an idempotency key, and alert when a saga sits in a non-terminal state longer than its expected completion window — a stuck saga is a silent version of 2PC's blocking problem, just without the lock.

Start from who owns the data, not from which pattern sounds more modern. All participants share one database, or one XA-capable transaction manager, and the transaction is short: 2PC (or your database's native distributed transaction) still works — this is common inside a single distributed SQL cluster, rare across independently-owned microservices. Participants are separate services with separate databases, possibly owned by different teams, and the process can take seconds to days: use a saga.

The deciding question is whether you can tolerate a lock held across services for the duration of the slowest participant. A trip booking that waits on an airline's API cannot hold a cross-service lock for that round trip — a saga's committed-then-compensate model is the only one that keeps each service independently available while the slow step runs.