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.

Architecture	Transaction Scope	Complexity
Monolithic	Single database, ACID guaranteed	Simple
Microservices	Multiple databases, requires coordination	Complex

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)

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 respond “ready”, coordinator commits; otherwise, rolls back

Rollback Scenario

When any service fails during prepare or commit:

1. Coordinator detects the failure
2. Sends rollback request to all participants
3. Each participant undoes prepared changes
4. Transaction aborts and client is notified

Pros and Cons

Pros	Cons
Strong consistency	Blocking (participants wait for coordinator)
Atomic guarantees	Single point of failure
Simple mental model	Complex failure recovery

SAGA Pattern

A series of local transactions with compensating actions to undo changes on failure. Focuses on eventual consistency rather than strong consistency.

How It Works

1. Each service performs its local transaction and emits an event
2. Next service listens, processes, and emits its own event
3. On failure, compensating transactions revert previous changes

Example: Order Service creates order → emits “OrderCreated” → Payment Service processes payment → emits “PaymentBilled” → if Payment fails, Order Service reverts the order.

SAGA Types

Choreography-Based

No central orchestrator. Services communicate via events directly.

Pros	Cons
Decentralized and scalable	Complex event management
No single point of failure	Hard to track transaction state
Good for simple workflows	Debugging is challenging

Orchestration-Based

A central orchestrator manages the transaction flow and rollbacks.

Pros	Cons
Centralized control	Single point of failure
Easier to manage and debug	Orchestrator can become bottleneck
Clear transaction visibility	Requires orchestrator infrastructure

2PC vs SAGA Comparison

Aspect	2PC	SAGA
Coordination	Centralized coordinator	Choreography (decentralized) or Orchestration (centralized)
Communication	Synchronous	Asynchronous
Consistency	Strong (ACID)	Eventual
Performance	Slower (blocking)	Faster (non-blocking)
Failure Handling	Rollback all	Compensating transactions
Best For	Short transactions, few participants	Long-running, complex workflows

When to Use What

Scenario	Recommended Pattern
Financial transactions requiring atomicity	2PC
E-commerce order with multiple services	SAGA (Orchestration)
Event-driven microservices	SAGA (Choreography)
Cross-database transactions in same region	2PC
Geo-distributed services	SAGA

TLDR

• 2PC: Strong consistency through blocking coordination. Use when atomicity is critical and participants are few.
• SAGA: Eventual consistency through compensating actions. Use for long-running, complex distributed workflows.
• Choose based on consistency requirements vs. availability and performance needs.