KAVRIQ
Interview contents

Saga Pattern

Introduction

In monolithic systems, transactions are typically handled by a single database transaction:

  • ACID guarantees (Atomicity, Consistency, Isolation, Durability) ensure reliability.

But in microservices architectures, each service owns its own database.

  • Global transactions spanning multiple services are not feasible.
  • Two-phase commit (2PC) is too slow and fragile for distributed systems.

The Saga Pattern solves this by coordinating distributed transactions through a sequence of local transactions, with compensating actions to roll back when failures occur.

Intent

The Saga Pattern’s intent is to manage distributed transactions across microservices by breaking them into a series of local transactions, coordinated via choreography or orchestration, with compensating actions for failure recovery.

Structure

Core Concepts

  1. Saga

    • A sequence of local transactions.
    • Each transaction updates its service’s database and publishes an event.

  2. Compensating Transaction

    • Undo logic when a step fails.

  3. Coordination Styles

    • Choreography – Services listen to each other’s events.
    • Orchestration – Central coordinator tells services what to do.
sequenceDiagram
  participant A as Order Service
  participant B as Payment Service
  participant C as Inventory Service


  A->>B: Reserve Payment
  B-->>A: Payment Reserved
  A->>C: Reserve Inventory
  C-->>A: Inventory Reserved
  Note over A,C: Saga completes if all succeed

Participants

  1. Services with Local Transactions

    • Each service owns data + transaction.

  2. Events

    • Communicate success/failure.

  3. Compensating Actions

    • Undo local changes if needed.

  4. Coordinator

    • Can be implicit (choreography) or explicit (orchestration).

Collaboration Styles

Choreography (Event-Driven)

  • Services communicate by publishing/subscribing to events.
  • No central controller.

✅ Simple, decentralized.
❌ Harder to track flow.

Orchestration (Central Controller)

  • A saga orchestrator tells each service to execute steps.

✅ Clear control, visibility.
❌ Central point of failure.

Implementation in Java

Example: E-commerce Order Saga

Choreography Style

Order Service (Producer)

@Service
public class OrderService {
    private final KafkaTemplate<String, String> kafka;


    public void placeOrder(Order order) {
        // Save order with status PENDING
        kafka.send("orders", "OrderCreated:" + order.getId());
    }
}

Payment Service (Consumer)

@Service
public class PaymentService {
    @KafkaListener(topics = "orders")
    public void handleOrder(String event) {
        if(event.startsWith("OrderCreated:")) {
            // Reserve payment...
            kafka.send("payments", "PaymentReserved:" + orderId);
        }
    }
}

Inventory Service (Consumer)

@Service
public class InventoryService {
    @KafkaListener(topics = "payments")
    public void handlePayment(String event) {
        if(event.startsWith("PaymentReserved:")) {
            // Reserve inventory...
            kafka.send("inventory", "InventoryReserved:" + orderId);
        }
    }
}

✅ Decentralized coordination.

Orchestration Style

Saga Orchestrator

@Service
public class OrderSagaOrchestrator {
    private final PaymentClient paymentClient;
    private final InventoryClient inventoryClient;


    public void execute(Order order) {
        try {
            paymentClient.reserve(order);
            inventoryClient.reserve(order);
            // Mark order as confirmed
        } catch (Exception e) {
            paymentClient.compensate(order);
            inventoryClient.compensate(order);
            // Mark order as failed
        }
    }
}

✅ Centralized coordination.

Consequences

Benefits

  1. Distributed Transactions Without 2PC – Works with independent DBs.
  2. Resilience – Failures handled via compensating actions.
  3. Scalability – Each service owns local transaction.
  4. Flexibility – Works with event-driven and orchestrated systems.

Drawbacks

  1. Complexity – Requires careful design.
  2. Compensating Logic – Not always straightforward.
  3. Choreography Spaghetti – Hard to manage at scale.
  4. Orchestrator Bottleneck – Central point of failure.

Real-World Case Studies

1. E-commerce (Amazon)

  • Orders, Payments, and Inventory coordinated via sagas.
  • Uses event-driven choreography for resilience.

2. Banking Systems

  • Money transfer = distributed transaction.
  • Debit one account, credit another → saga ensures rollback on failure.

3. Travel Booking (Flights, Hotels, Cars)

  • Bookings involve multiple services.
  • Sagas ensure consistency across vendors.

Extended Java Case Study

Scenario: Flight Booking

  1. Book flight.
  2. Reserve hotel.
  3. Rent car.
  4. If car rental fails → compensate (cancel hotel + flight).
public class TravelSaga {
    private final FlightClient flight;
    private final HotelClient hotel;
    private final CarClient car;


    public void bookTrip(TripRequest req) {
        try {
            flight.book(req);
            hotel.reserve(req);
            car.rent(req);
        } catch(Exception e) {
            car.compensate(req);
            hotel.cancel(req);
            flight.cancel(req);
        }
    }
}

✅ End-to-end consistency.
✅ Compensations ensure rollback.

Interview Prep

Q1: What is the Saga Pattern?

Answer: A pattern for managing distributed transactions by sequencing local transactions and using compensating actions on failure.

Q2: What are choreography vs orchestration?

Answer: Choreography = decentralized via events. Orchestration = centralized controller.

Q3: What are pros and cons?

Answer: Pros: resilience, no 2PC. Cons: complexity, compensating logic.

Q4: Where is Saga used?

Answer: E-commerce, banking, travel booking.

Q5: How does Saga differ from 2PC?

Answer: Saga = eventual consistency with compensation. 2PC = strong consistency but low scalability.

Visualizing Saga Pattern

Choreography

sequenceDiagram
  participant O as Order
  participant P as Payment
  participant I as Inventory


  O->>P: OrderCreated Event
  P->>I: PaymentReserved Event
  I-->>O: InventoryReserved Event

Orchestration

sequenceDiagram
  participant Or as Orchestrator
  participant P as Payment
  participant I as Inventory


  Or->>P: Reserve Payment
  P-->>Or: Success
  Or->>I: Reserve Inventory
  I-->>Or: Success

Key Takeaways

  • Saga Pattern manages distributed transactions without 2PC.
  • Two styles: Choreography (event-driven) and Orchestration (central controller).
  • Requires compensating transactions to handle failures.
  • Widely used in e-commerce, banking, and travel systems.

Next Lesson

Next, we’ll cover the Strangler Fig Pattern — gradually modernizing legacy systems by incrementally replacing parts with new implementations.

Continue to Strangler Fig Pattern →