Distributed Transactions: 2PC vs Saga

The moment your flow touches two databases or microservices, you need a plan for partial failure. We choose between blocking 2PC coordination and async sagas with compensating actions.

When work spans multiple databases, we choose blocking coordination (2PC) or async steps with compensations (Saga):

Cross-service writes need an explicit consistency story — 2PC, saga, or outbox. We frame the choice around three lenses:

Walk both patterns as parallel interview paths. 2PC path: coordinator prepares all participants, waits for votes, then commits or aborts — strong consistency, blocking under partition. Saga path: each service commits locally and publishes events; compensating transactions undo on failure — eventual consistency, no global lock. Outbox path: write business row and outbox row in one local transaction; relay publishes to the bus — at-least-once with idempotent consumers.

Saga Compensation Model

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

We compare 2PC and saga on latency, failure behavior, and operational complexity:

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

• Saga Coordination Strategies: Mapping flow control styles:

Strong cross-service atomicity and availability pull apart — we state both sides:

Coordinator failure, poison messages, and duplicate delivery are saga interview staples — we name mitigations:

Checkout, booking, and payment flows are where these patterns appear on the whiteboard:

The transactional outbox bridges a local DB commit and an outbound event — the row and the outbox entry commit atomically, then a relay publishes to the message bus:

For Strangler migration and outbox at the microservices layer, see Microservices Patterns: Strangler, Saga, & Outbox (#30).

Think distributed transactions when a user action spans multiple services that must agree or compensate:

Sagas connect to message queues, idempotency, and microservices outbox patterns:

• Microservices Patterns: Strangler, Saga, & Outbox (#30) — production outbox/CDC wiring and Strangler migration context.
• 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).

When 2PC Is Not Enough: TCC & 3PC (Brief)

TCC (Try-Confirm-Cancel) splits each service call into a reserve phase (Try), a commit (Confirm), and an undo (Cancel) — common in payment holds where 2PC row locks are too heavy. 3PC adds a pre-commit phase to reduce coordinator-failure blocking but is rarely implemented in production; interviewers mention it to show you know 2PC's coordinator stall problem. Default recommendation remains: 2PC inside one region with few participants, Saga + outbox for cross-service flows.