Saga Pattern

#Introduction

Purpose: maintain business consistency across multiple services using local transactions and compensating transactions.

In a monolith, creating an order, charging payment and reserving stock can share one database transaction — if any step fails, everything rolls back. In microservices, each service owns its own database, so there's no single transaction spanning them, and distributed two-phase commit (2PC) is slow, fragile and unsupported by most message brokers and cloud databases.

A saga is a sequence of local transactions, one per service. If a step fails, the saga runs compensating transactions that undo the work of the steps that already succeeded.

#Example: Placing an Order

If inventory fails:

Compensations run in reverse order.

The Services

class OrderService {
    public void createOrder()  { System.out.println("Order Created"); }
    public void cancelOrder()  { System.out.println("Order Cancelled"); }
}

class PaymentService {
    public void processPayment() { System.out.println("Payment Completed"); }
    public void refundPayment()  { System.out.println("Payment Refunded"); }
}

class InventoryService {
    public void reserveInventory() {
        System.out.println("Reserving Inventory...");
        throw new RuntimeException("Inventory unavailable");
    }

    public void releaseInventory() {
        System.out.println("Inventory Released");
    }
}

The Saga

class OrderSaga {
    private final OrderService orderService = new OrderService();
    private final PaymentService paymentService = new PaymentService();
    private final InventoryService inventoryService = new InventoryService();

    public void execute() {
        boolean orderCreated = false;
        boolean paymentCompleted = false;
        boolean inventoryReserved = false;

        try {
            orderService.createOrder();            // T1
            orderCreated = true;

            paymentService.processPayment();       // T2
            paymentCompleted = true;

            inventoryService.reserveInventory();   // T3
            inventoryReserved = true;

            System.out.println("Saga Completed Successfully");

        } catch (Exception e) {
            System.out.println("Saga Failed: " + e.getMessage());

            // Compensations are performed in reverse order
            if (inventoryReserved) {
                inventoryService.releaseInventory();
            }
            if (paymentCompleted) {
                paymentService.refundPayment();
            }
            if (orderCreated) {
                orderService.cancelOrder();
            }

            System.out.println("Saga Compensation Completed");
        }
    }
}

public class Main {
    public static void main(String[] args) {
        new OrderSaga().execute();
    }
}

Order Created
Payment Completed
Reserving Inventory...
Saga Failed: Inventory unavailable
Payment Refunded
Order Cancelled
Saga Compensation Completed

Inventory was never reserved (T3 failed), so only C2 and C1 run.

#Choreography

There's no central coordinator. Each service listens for events and reacts by doing its local transaction and publishing the next event:

Memory trick: event → reaction → event → reaction.

On failure, the failing service publishes a failure event (InventoryReservationFailed), and upstream services listen for it and run their compensations (Payment refunds, Order cancels).

#Orchestration

A central orchestrator tells each service what to do and decides what happens next:

class SagaOrchestrator {
    public void execute() {
        createOrder();
        processPayment();
        reserveInventory();
        createShipment();
    }
}

The orchestrator decides: what happens next? what succeeded? what failed? which compensation should run? In real systems it sends commands (often as messages) and stores the saga's state in a database, so it can resume after a crash.

#Choreography vs Orchestration

#Making Sagas Reliable in Production

The in-memory example shows the idea; real sagas must handle failures between steps:

#Saga vs Two-Phase Commit

#When to Use

• A business operation spans several services, each with its own database.
• Eventual consistency is acceptable, and every step has a meaningful business compensation.
• Not needed when the operation fits in one service and one database — use a normal local transaction.

#Key Takeaways

• A saga keeps data consistent across services with local transactions plus compensations.
• Compensations run in reverse order and are new business transactions, not rollbacks.
• Choreography = events and no central boss; orchestration = a central coordinator.
• Production sagas need idempotency, persisted state and the transactional outbox.
• Sagas give eventual consistency instead of 2PC's blocking strong consistency.