Distributed Transaction (2PC & Saga)

What is a Distributed Transaction?

A distributed transaction is a set of operations that spans multiple, separate transactional resources (like databases, message queues, or microservices). The challenge is to ensure that the entire set of operations either succeeds completely across all resources, or fails completely, leaving the overall system state consistent, even in the face of partial failures (where some resources succeed but others fail).

The Challenge: ACID vs. BASE

Traditional databases offer ACID guarantees (Atomicity, Consistency, Isolation, Durability), ensuring transactions are all-or-nothing. Achieving strong ACID across independent distributed services is difficult and often violates the CAP Theorem (Consistency, Availability, Partition tolerance - you can typically only have two).

Distributed systems often favor Availability and Partition tolerance, leading to models like BASE (Basically Available, Soft state, Eventually consistent). This requires different approaches to managing transactions across services.

Two-Phase Commit (2PC)

2PC is a classic protocol aiming to provide atomic commitment across distributed participants. It involves a central Coordinator and multiple Participants (the services/databases involved).

• Phase 1: Prepare (Voting) Phase
  1. The Coordinator sends a PREPARE message to all Participants.
  2. Each Participant determines if it can commit the transaction part locally. It prepares by locking resources, performing work, and writing undo/redo logs.
  3. If successful, the Participant votes YES (Prepared) back to the Coordinator. If it fails or decides it cannot commit, it votes NO (Abort).
  4. Participants that vote YES enter a prepared state and must wait for the Coordinator's final decision.
• Phase 2: Commit/Abort Phase
  1. The Coordinator collects votes:
     • If all Participants voted YES, the Coordinator decides to COMMIT.
     • If any Participant voted NO (or timed out), the Coordinator decides to ABORT.
  2. The Coordinator sends the final decision (COMMIT or ABORT) to all Participants.
  3. Participants receive the decision:
     • If COMMIT, they finalize the transaction (apply changes, release locks).
     • If ABORT, they undo any changes made during prepare (using undo logs) and release locks.
  4. Participants acknowledge the final action to the Coordinator.

Pros: Provides atomicity (all-or-nothing guarantee).

Cons: Blocking (Participants lock resources and wait in the prepared state), Coordinator is a single point of failure (if it crashes after Prepare but before Commit/Abort, Participants are stuck), performance overhead due to multiple message rounds.

Saga Pattern

A Saga manages data consistency across microservices without relying on distributed locking or a single atomic transaction. It's a sequence of local transactions. Each local transaction updates its service's database and triggers the next local transaction in the Saga.

If a local transaction fails, the Saga executes a series of compensating transactions in reverse order to undo the work completed by preceding successful transactions.

• Local Transactions: Each step in the business process is executed as a local ACID transaction within a single service.
• Compensating Transactions: For every local transaction `T`, there must be a corresponding compensating transaction `C` that semantically undoes the effect of `T`. Compensation must be carefully designed and should ideally be idempotent (safe to run multiple times).
• Coordination (Orchestration vs. Choreography):
  • Orchestration (Visualized Here): A central Orchestrator (or Coordinator) manages the Saga flow. It calls each service to perform its local transaction and triggers compensating transactions if failures occur.
  • Choreography: Each service publishes events when its local transaction completes. Other services listen for these events and trigger their own local transactions. Failure handling is distributed. (More complex to visualize).

Pros: Non-blocking (no distributed locks), improved availability (failure in one service doesn't block others indefinitely), fits well with microservice architecture.

Cons: Eventual Consistency (no atomicity in the ACID sense, temporary inconsistencies exist until compensation completes), complex to implement (designing reliable compensating actions is hard), debugging across services can be difficult.