Distributed Transactions & SAGA Pattern

Distributed Systems
16 / 21

How to maintain data consistency across multiple services/databases when a single ACID transaction cannot span service boundaries.

CoordinatorParticipant1. PREPARE (Phase 1)2. VOTE YES3. COMMIT (Phase 2)
SD blueprint: 2-Phase Commit (2PC) Timeline
The Analogy (Read This First)

You book a holiday: flight ($500), hotel ($300), rental car ($150). If the hotel is fully booked, you must undo the flight booking and the car reservation. This multi-step process that needs all-or-nothing semantics across independent systems is a distributed transaction. SAGA manages this by executing each step and explicitly undoing previous steps if one fails.

Deep Dive Analysis

In a monolith, a database transaction wraps all operations: BEGIN TRANSACTION; debit card; reserve seat; send email; COMMIT. ACID guarantees: if any step fails, all roll back.

In microservices, each service owns its own database. You cannot wrap a transaction across PaymentService.Postgres + InventoryService.MongoDB + EmailService.MySQL. They are completely separate systems.

Two-Phase Commit (2PC): A coordinator asks all participants to PREPARE (lock resources). If all say "yes, ready", the coordinator sends COMMIT. If any says "no", sends ABORT. Drawback: blocking protocol - if the coordinator crashes after PREPARE but before COMMIT, all participants are locked forever waiting. High latency. Rarely used in microservices.

SAGA Pattern: Decomposes a distributed transaction into a sequence of local transactions, each with a corresponding compensating transaction for undo. Two styles:

Choreography-based SAGA: Each service listens for events and publishes events. No central coordinator. Example: OrderService publishes "OrderCreated" → InventoryService reserves stock and publishes "StockReserved" → PaymentService charges card and publishes "PaymentProcessed" → EmailService sends confirmation. If PaymentService fails: publishes "PaymentFailed" → InventoryService listens and releases reservation → OrderService marks order as failed.

Orchestration-based SAGA: A central SAGA Orchestrator explicitly calls each service and handles failures. More complex but easier to track state, debug, and manage. Orchestrator holds the whole workflow. If any step fails, orchestrator explicitly calls compensating endpoints.

Key Bullets
  • SAGA trades atomicity for availability - temporary inconsistency is acceptable in exchange for system resilience.
  • Compensating transactions must be idempotent - they may be called multiple times.
  • Choreography: loose coupling, hard to track overall state. Orchestration: tight coupling, easy to monitor.
  • SAGA state must be durably persisted (in a DB) so the orchestrator survives crashes.
  • Use where: e-commerce checkout, hotel/flight booking, multi-step financial workflows.
Real-World Examples
Temporal.io: workflow orchestration for SAGA (used by Netflix, Stripe)AWS Step Functions: managed orchestration SAGAEventuate Tram: open-source SAGA framework for Spring/NodeApache Camel: choreography-based event routing

Curated Curation & Deep Insights

ScaleDojo Certified
Video Tutorial Pending

Our system architects are vetting high-quality, authorized video guides for Distributed Transactions & SAGA Pattern with zero third-party platform links.

Verification in Progress
Reading Material Pending

We are preparing premium, zero-competitor deep-dives for Distributed Transactions & SAGA Pattern. Authorized reading references will appear automatically.

Verification in Progress
ScaleDojo Logo
Initializing ScaleDojo