Distributed Transaction Handling

What is a Transaction

• A transaction is a group of operations executed as a single unit, ensuring data integrity and consistency.
• Key Principle: All or Nothing - if any operation fails, the entire transaction is rolled back.
• Example: Transferring money:
  • Debit from Person A and credit to Person B. If any step fails, rollback the entire transaction.
• ACID Properties ensure reliability in transactions.

Monolithic Architecture: Transaction Management

Definition: A single, unified application where all components (database, business logic, UI) are tightly integrated.

• Transaction Process:

  1. Inventory Check and Update
  2. Payment Processing
  3. Order Recording

• Key Point: All steps occur in a single database transaction, ensuring ACID properties.

• Advantage: Simple transaction management due to centralized data.

Microservices Architecture: Transaction Management

Definition: Independent services, each with its own data store, coordinating through APIs and events.

• Transaction Process:

  1. Inventory Service: Checks and updates stock.
  2. Payment Service: Processes payment.
  3. Order Service: Records the order.

• Key Point: Transactions span multiple services and databases, requiring compensating actions for failures.

• Challenge: Complex transaction management due to distributed nature.

Hint

• Monolithic architecture: simple transaction management due to centralized data and services.
• Microservices architecture: more complex transaction management, requiring additional mechanisms to maintain consistency.

What is a Distributed Transaction?

• A transaction that spans multiple services and databases in a microservices architecture.

Solutions for Microservice Transactions

Two-Phase Commit (2PC) Pattern

• Definition: A protocol ensuring all services agree to commit or roll back changes together.
• Phases:
  1. Prepare Phase: Coordinator asks all services to prepare (lock resources and verify readiness).
  2. Commit Phase: If all services are ready, the coordinator commits changes; otherwise, it rolls back.
• Benefits:
  • Strong consistency.
  • Ensures atomicity (all or nothing).
• Disadvantages:
  • Blocking: Participants wait for the coordinator, causing delays.
  • Single Point of Failure: Coordinator failure can halt the transaction.
  • Complex Recovery: Handling failures is challenging.

Example of 2PC Implementation

1. Put Order Request:
   • The user places an order, triggering the global coordinator to start a transaction.
2. Prepare Phase:
   • The coordinator requests CustomerMicroservice to prepare by checking and locking customer funds.
   • Simultaneously, it requests OrderMicroservice to prepare for order creation.
3. Commit Phase:
   • If both services are prepared, the coordinator requests them to commit the changes.
   • If any service fails, the coordinator sends a rollback request to undo any partial changes.

SAGA Pattern

• Definition: A series of local transactions, each with compensating actions to undo changes if a failure occurs.
• Focus on eventual consistency.
• How it Works:
  • Each service performs its local transaction and emits events.
  • If a failure occurs, compensating transactions are triggered to revert changes.
• Types:
  1. Choreography-Based SAGA:
     • Decentralized services communicate via events.
     • Pros: Scalable, no central orchestrator.
     • Cons: Complex event management.
  2. Orchestration-Based SAGA:
     • Centralized; an orchestrator manages the transaction flow.
     • Pros: Easier to manage.
     • Cons: Single point of failure.

Advantages

1. Support for Long-Lived Transactions:
   • Each microservice handles its own local transaction independently.
   • Avoids blocking, allowing transactions to proceed even with user input.
2. Parallel Execution:
   • Transactions can execute in parallel across services.
   • Avoids locks on objects, improving performance and scalability.

Disadvantages

1. Complex Debugging:
   • Debugging distributed transactions is challenging, especially in systems with many microservices and asynchronous events.
2. Event Management:
   • As the system grows, managing and maintaining event messages becomes increasingly difficult.
   • Requires robust event tracking and monitoring mechanisms.
3. Read Isolation Issues:
   • No read isolation is guaranteed.
   • Users may see inconsistent states if compensating transactions are triggered to undo changes.

How Does the SAGA Pattern Work?

In the SAGA pattern, distributed transactions are fulfilled through asynchronous local transactions across microservices. Microservices communicate using an event bus, with each service handling its own local transactions and emitting events to coordinate with other services.

Example Scenario: Customer Order

1. Order Service receives a request to place an order and starts a local transaction to create the order.
2. The Order Service emits an “OrderCreated” event.
3. The Customer Service listens for this event, updates the customer’s funds, and emits a “CustomerFundUpdated” event.
4. If any service fails during its local transaction, compensation transactions are triggered to revert changes.

Compensation Example:

• If the Customer Service fails and emits a “CustomerFundUpdateFailed” event, the Order Service will initiate a compensation transaction to revert the created order.

Types of SAGA

• Choreography-Based SAGA
• Orchestration-Based SAGA

Choreography-Based SAGA

In a Choreography-Based SAGA, there is no central orchestrator. Each service handles its own transactions and communicates using events:

1. Order Service initiates the process and emits “OrderCreated”.
2. Payment Service processes the payment and emits “PaymentBilled”.
3. Stock Service updates stock and emits “StockPrepared”.
4. If any service encounters an error, compensation transactions are triggered based on failure events.

Pros:

• Decentralized and scalable for simpler workflows.

Cons:

• Complexity increases with more steps; managing events and state transitions can be challenging.

Orchestration-Based SAGA

In an Orchestration-Based SAGA, a central orchestrator manages the transaction:

1. Order Service triggers the orchestrator.
2. The Orchestrator coordinates the sequence of events and calls services.
3. If a service fails, the orchestrator manages rollback by triggering compensation transactions for all previous steps.

Pros:

• Centralized control makes it easier to manage the process.

Cons:

• Scalability issues and potential single point of failure. Recovery mechanisms or a choreography-based approach might be preferred in some cases.

2PC vs SAGA

Aspect	2PC	SAGA
Coordination	Centralized	Decentralized (Choreography) or Centralized (Orchestration)
Communication	Synchronous	Asynchronous
Atomicity	Strong Atomicity	Eventual Consistency
Performance	Slower due to blocking	Faster with independent operations
Flexibility	Less flexible, single point of failure	More flexible, resilient
Use Cases	Strong consistency, limited participants	Long-running, complex transactions