A saga coordinates business consistency across services when one database transaction can no longer do the job.

Sagas manage multi-step workflows across service boundaries using local transactions plus compensating actions. They are not magic replacements for ACID across the platform. They are a way to make business processes recoverable when ordering, payment, inventory, and shipment each own their own persistence and lifecycle.

OOAD landing page Learning roadmap Previous: Event Sourcing Next: Outbox Pattern

Why This Topic Matters

Why it matters in real Java systems

Placing an order may reserve inventory, authorize payment, and create shipment planning. If payment fails after reservation succeeds, the system needs a business recovery path. A saga names that recovery path explicitly instead of relying on impossible cross-service rollback semantics.

Core Explanation

The main design idea

Sagas break a large distributed transaction into local transactions linked by messages or commands. If a later step fails, compensating actions undo or mitigate earlier work where the business allows it. There are two common coordination styles. Orchestration uses a central coordinator. Choreography lets services react to events without one central controller. Both can work, but both require careful state thinking.

The main discipline is business realism. Not every action is fully reversible. Compensation may mean refunding, releasing stock, or marking a case for manual review. A saga succeeds when the business outcome becomes explicit and recoverable, not when it pretends rollback is free.

Concept Breakdown

Key ideas to keep in mind

Concept

Local transactions

Each service commits its own work independently.

Concept

Compensation

Failures trigger business-aware recovery actions, not low-level rollback fantasies.

Concept

Coordination style

Choose orchestration for visibility or choreography for looser coupling, based on workflow complexity.

Orchestration vs choreography

Style	Good fit	Watch for
Orchestration	Complex workflows that need visible central coordination	Over-centralized process logic becoming a hidden monolith
Choreography	Looser event collaboration with simpler flows	Implicit coupling and hard-to-follow event chains

Java Example

Java example in the Order Management domain

Java example: simple orchestrated saga

package org.javaomnibus.orders.saga;

public final class PlaceOrderSaga {
    private final InventoryService inventoryService;
    private final PaymentService paymentService;

    public PlaceOrderSaga(InventoryService inventoryService, PaymentService paymentService) {
        this.inventoryService = inventoryService;
        this.paymentService = paymentService;
    }

    public void execute(OrderId orderId, List<OrderLine> lines, Money total) {
        inventoryService.reserve(orderId, lines);
        try {
            paymentService.authorize(orderId, total);
        } catch (RuntimeException failure) {
            inventoryService.release(orderId);
            throw failure;
        }
    }
}

Code Walkthrough

Step by step

This small example shows the core idea: local steps plus compensation.
In real systems, saga state usually persists and advances through messages rather than one synchronous method.
The release step is business compensation, not infrastructure rollback.
That distinction is the heart of the pattern.

Real-World Usage

Where this helps in practice

Order placement workflows across ordering, inventory, payment, and fulfillment
Refund, cancellation, and return processes that cross service boundaries
Any long-running business process with independently owned data

Trade-Offs

Trade-offs and when to be careful

Sagas improve recoverability, but they increase workflow state complexity and operational debugging needs.
Orchestrated sagas are easier to understand centrally, while choreographed sagas reduce central coordination at the cost of visibility.

Common Mistakes

Frequent mistakes to watch for

Assuming compensation is always exact rollback
Choosing choreography for very complex workflows with poor observability
Skipping idempotency on saga steps and compensations
Not modeling manual intervention states for irrecoverable cases

Related concepts

Outbox pattern Distributed system failures Application Services vs Domain Services