Saga vs Two-Phase Commit

Distributed transactions are one of the hardest problems in system design. The Saga pattern and Two-Phase Commit (2PC) offer different trade-offs for maintaining data consistency across multiple services.

Two-Phase Commit

2PC uses a coordinator that asks all participants to prepare, then commits or aborts atomically. It guarantees ACID properties across distributed systems but at a steep cost: participants hold locks during the prepare phase, blocking other operations.

If the coordinator crashes between prepare and commit, participants are stuck in an "in-doubt" state, unable to commit or rollback until the coordinator recovers. This makes 2PC unsuitable for microservices that need high availability.

The Saga Pattern

A Saga breaks a distributed transaction into a sequence of local transactions. Each service commits its own transaction and publishes an event. If a step fails, compensating transactions undo previous steps.

For example, an order saga might: (1) create order, (2) reserve inventory, (3) charge payment. If payment fails, compensating transactions release inventory and cancel the order.

Choreography vs Orchestration

Sagas can be implemented as choreography (services react to events) or orchestration (a central coordinator drives the workflow). See our choreography vs orchestration comparison for the trade-offs.

The Isolation Problem

The biggest challenge with sagas is lack of isolation. Between saga steps, intermediate states are visible. A user might see their order as "created" before payment succeeds. This requires careful UI design and semantic locks.

For interview preparation, review the Saga pattern concept and system design interview guide. See pricing for full access.

The Bottom Line

Use 2PC only within a single database or tightly coupled subsystem where strong consistency is essential. Use sagas for distributed transactions across microservices where availability and scalability matter more.