🚨 Everything starts with a problem

When working with microservices, each service typically owns its own database — and that’s great for independence and scalability.
But… what happens when you need a single business operation that spans multiple services?

Imagine booking a trip:

1. ✈️ Book a flight
2. 🏨 Reserve a hotel
3. 🚗 Rent a car

If the hotel reservation fails, you don’t want the flight and car to stay booked — you need to roll back the entire process.

In a traditional monolithic application, ensuring data consistency is straightforward — you simply rely on ACID transactions (Atomicity, Consistency, Isolation, Durability). The database guarantees that either the entire operation succeeds, or none of it does.

However, once you split your system into multiple microservices, each with its own database, maintaining this level of consistency becomes much harder. There’s no single transaction spanning all services — and that’s where distributed consistency patterns come in.

Let’s see what option we have 👇

1️⃣ Two-Phase Commit (2PC) / Distributed Transactions

The Two-Phase Commit protocol is a distributed algorithm that guarantees atomicity across multiple participating services and their respective databases. It attempts to create a single, ACID-like transaction in a distributed system by having a central Coordinator manage the process. The core guarantee is that either all participants commit the transaction, or all roll it back—there is no partial success.

Pros

• Strong Consistency: Guarantees atomicity across multiple services, ensuring that the entire distributed operation either succeeds completely or fails completely.
• Data Integrity: Provides the highest level of data integrity for cross-service operations.
• Familiar Model: Conceptually simple for developers, as it mirrors the familiar ACID transaction model used in traditional monolithic databases.

Cons

• Blocking (Low Performance): Participants hold locks on resources (e.g., database records) during the entire protocol. This severely reduces system throughput and increases latency.
• Single Point of Failure: The Coordinator is a critical component. If it fails after a participant has successfully voted to commit but before the final outcome is broadcast and executed, participating services can become indefinitely blocked (a “hanging transaction”), requiring manual intervention to resolve.
• Not Scalable (Low Availability): Due to the blocking nature and dependency on a single Coordinator, 2PC drastically limits the scalability and availability of the distributed system, which goes against the core philosophy of microservices.

2️⃣ Saga

A Saga is a sequence of local transactions in different services, linked together through events or commands.

Each step:

• performs a local transaction
• defines a compensating action to undo it if something fails later.

Example:

1. ✈️ Reserve flight
2. 🏨 Reserve hotel
3. ❌ If hotel fails → Cancel flight

This pattern achieves eventual consistency instead of strong consistency.
Instead of “all or nothing”, we say:

“Eventually, everything will be consistent again.”

🔀 Two Ways to do a Saga

1️⃣ Choreography (Event-Driven)

Each service listens to events and emits new ones — no central controller.

🧩 Example:

┌────────────────────┐       emits "OrderCreated"       ┌────────────────────────────┐
│ 🧾 Order Service   │ ───────────────────────────────▶ │ 💳 Payment Service        │
│ creates order      │                                  │ handles "OrderCreated"     |
└────────────────────┘                                  └─────────┬──────────────────┘
                                                                  │ emits "PaymentCompleted"
                                                                  ▼
                                                      ┌─────────────────────────────┐
                                                      │ 📦 Inventory Svc            │
                                                      │ handles "PaymentCompleted"  │ 
                                                      └───────────┬─────────────────┘
                                                                  │ emits "InventoryReserved"
                                                                  ▼
                                                      ┌─────────────────────────────┐
                                                      │ 🚚 Shipping Service         │
                                                      │ handles "InventoryReserved" |
                                                      └─────────┬───────────────────┘
                                                                │ emits "OrderShipped"
                                                                ▼
                                                      ┌─────────────────────────┐
                                                      │ 🧾 Order Service        │ 
                                                      │ handles "OrderShipped"  │ 
                                                      │ Completes order         │ 
                                                      └─────────────────────────┘

If something fails:

• Each service performs its compensating action and emits corresponding event, Payment Service emits PaymentReversed, Inventory Service emits StockRestored.

✅ Pros:

• No central dependency.
• Works great for simple flows.

⚠️ Cons:

• Harder to debug (“event spaghetti”).
• The process flow is spread across many services.

2️⃣ Orchestration (Central Coordinator)

A single Orchestrator (Saga Manager) coordinates all the steps.

🧩 Example:

┌────────────────────┐             CreateOrder              ┌────────────────────┐
│ Orchestrator       │ ───────────────────────────────────▶ │ Order Service      │
│                    │                                      │ creates order      │
└─────────┬──────────┘                                      └─────────┬──────────┘
          │                                                           │
          │                                                           │
          │ ◀─────────────────── CreateOrderResponse ─────────────────┘
          ▼
┌────────────────────┐       ProcessPayment                 ┌────────────────────┐
│  Orchestrator      │ ───────────────────────────────────▶ │  Payment Service   │
│                    │                                      │ charges customer   │
└─────────┬──────────┘                                      └─────────┬──────────┘
          │                                                           │
          │ ◀───────────────── ProcessPaymentResponse ────────────────┘
          ▼
┌────────────────────┐       ReserveInventory               ┌────────────────────┐
│    Orchestrator    │ ───────────────────────────────────▶ │  Inventory Svc     │
│                    │                                      │ reserves stock     │
└─────────┬──────────┘                                      └─────────┬──────────┘
          │                                                           │
          │ ◀──────────────── ReserveInventoryResponse ───────────────┘
          ▼
┌────────────────────┐              ShipOrder               ┌────────────────────┐
│    Orchestrator    │ ───────────────────────────────────▶ │ Shipping Service│
│                    │                                      │ ships order        │
└─────────┬──────────┘                                      └─────────┬──────────┘
          │                                                           │
          │ ◀─────────────────── ShipOrderResponse ───────────────────┘
          ▼
┌────────────────────┐
│ Orchestrator       │
│ marks order as     │
│  "Completed"       │
└────────────────────┘

If any step fails, the orchestrator calls the appropriate compensating commands, like CancelPayment or ReleaseInventory.

✅ Pros:

• Easier to visualize and debug.
• Centralized workflow control.

⚠️ Cons:

• Orchestrator becomes a new dependency (but much easier to manage than global locks).

💡 Real-life example

Let’s visualize a real-world example 👇

Let’s see how a Saga actually works in a real-world scenario.

Imagine we’re building an e-commerce platform with these microservices:

• 🧾 Order Service — creates and manages customer orders.
• 💳 Payment Service — charges the customer.
• 📦 Inventory Service — reserves and releases stock.
• 🚚 Shipping Service — handles delivery once everything is confirmed.

🗺️ Step-by-Step Flow

Here’s how an Order Saga might play out:

• 🧾 Customer places an order
  • The Order Service creates a new order with status = PendingPayment and publishes an event OrderCreated
• 💳 Payment Service charges the customer
  • It listens for OrderCreated
  • If payment succeeds, it emits PaymentCompleted
  • If it fails (e.g. insufficient funds), it emits PaymentFailed.
• 📦 Inventory Service reserves items
  • Upon receiving PaymentCompleted, it tries to reserve stock.
    • On success → emits StockReserved.
    • On failure → emits StockUnavailable.
• 🚚 Shipping Service prepares the shipment
  • When it sees StockReserved, it schedules delivery and emits OrderShipped.

Order Service updates final state, it listens for all these events and marks the order as:

• ✅ Completed when shipping succeeds.
• ❌ Failed when any previous step fails.

💥 What if Something Fails?

Here’s where the compensating transactions come into play.

If any step fails, we don’t roll back everything instantly (because each service already did its local transaction). Instead, we trigger compensations to undo the side effects:

┌────────────────────┐
│ 🧾 Order Service   │
│ creates order      │
└─────────┬──────────┘
          │
          │ emits "OrderCreated"
          ▼
┌────────────────────┐
│ 💳 Payment Service │
│ processes payment  │
└─────────┬──────────┘
          │
          │ emits "PaymentCompleted"
          ▼
┌────────────────────────────┐
│ 📦 Inventory Svc           │
│ fails to reserve items 💥  │
└─────────┬──────────────────┘
          │
          │ emits "StockReservationFailed"
          ▼
┌────────────────────────────┐
│ 🧾 Order Service receives  │
│  "StockReservationFailed"  │
│  cancells order            │
│  emits "OrderCancelled"    │
└─────────┬──────────────────┘
          │ emits "OrderCancelled"
          ▼
┌────────────────────┐
│ 💳 Payment Service │
│ listens to         │
│ "OrderCancelled"   │
│ and refunds user   │
└────────────────────┘

Each compensation is also just a local transaction, ensuring eventual consistency without distributed locks or 2PC.

⚙️ Implementation Tips

• 📨 Outbox Pattern:
  Use it to ensure your local transaction and event publishing happen atomically.

• 🧵 Message Brokers:
  Use Kafka, RabbitMQ, or Azure Service Bus for reliable messaging between services.

🧠 Frameworks That Help:

• MassTransit
• NServiceBus

📚 Additional Learning Material

• Compensating Transaction pattern
• Saga distributed transactions pattern