Distributed Transactions: 2PC vs Saga

Two-Phase Commit coordinates prepare and commit signals, holding locks until all nodes resolve:

Saga Compensation Model

Sagas execute local database commits instantly, executing rollback compensations backward on error:

• Two-Phase Commit (2PC) Properties: Lock-heavy, strongly consistent profile:

• Saga Coordination Strategies: Mapping flow control styles:

To safely bridge the database write and outbound event publishing boundary, systems deploy the **Transactional Outbox Pattern**:

• Message Queues Fundamentals: Relaying messages safely inside choreographies.
• Event Sourcing & CQRS: Reconstructing state histories from event logs.
• CAP Theorem & Consistency Models: Balancing read-write availability during network splits.

The Saga Lack of Isolation Problem

Unlike 2PC which holds absolute transaction row locks, Sagas commit local database operations instantly. This means Sagas completely violate the **Isolation (I)** property of ACID. Two distinct anomalies can occur in production:

1. Dirty Reads (Intermediate State): A customer queries their bank balance while a Saga money transfer is executing step 1 (Debit account) but before step 2 (Credit beneficiary). The reader sees a decreased balance that might rollback later if step 2 crashes.
2. Lost Updates (Overwriting writes): Step 1 debits balance. A separate concurrent operation updates the account balance without reading the Saga locks. When the Saga rolls back, its compensation overwrites the concurrent update.

**Production Countermeasures**: Implement application-level safeguards like **Pending Flags** (e.g. mark order status as `PENDING_PAYMENT` to prevent shipping actions) or use **Semantic Locks** (e.g. decrement a user's *available* balance, but preserve their *actual* balance until the Saga fully completes).