Implementing the Saga Pattern for Distributed Transactions with Apache Camel

The Distributed Transaction Problem

In a monolithic application, a database transaction gives you atomicity for free: either all operations succeed, or all are rolled back. In a distributed system — where an order creation touches an inventory service, a payment service, and a notification service — there is no shared transaction boundary. A failure in any one service can leave the system in an inconsistent state.

The Saga pattern addresses this by decomposing a distributed operation into a sequence of local transactions, each with a corresponding compensating transaction that undoes its effect if a later step fails.

Choreography vs Orchestration

There are two styles of Saga:

• Choreography — each service publishes events and reacts to events from other services. Loosely coupled but hard to reason about as the flow grows.
• Orchestration — a central orchestrator (the Saga) explicitly calls each service and triggers compensations on failure. Easier to trace and debug.

Apache Camel implements the orchestration style natively with its Saga EIP, introduced in Camel 2.21.

Apache Camel Saga EIP

Each step in the Camel saga route declares a compensation action. If any step throws an exception, Camel automatically invokes the compensation actions for all previously completed steps in reverse order.

from("direct:create-order")
  .saga()
    .step()
      .to("direct:reserve-inventory")
      .compensation("direct:release-inventory")
    .step()
      .to("direct:charge-payment")
      .compensation("direct:refund-payment")
    .step()
      .to("direct:send-confirmation-email")
      // no compensation needed — email is fire-and-forget
  .end()
  .log("Order ${header.orderId} created successfully");

Each compensation route is a normal Camel route that receives the same exchange headers as the original step, giving it enough context to perform the rollback:

from("direct:release-inventory")
  .log("Releasing inventory for order ${header.orderId}")
  .to("bean:inventoryService?method=release");

from("direct:refund-payment")
  .log("Refunding payment for order ${header.orderId}")
  .to("bean:paymentService?method=refund");

Saga in SAP Landscapes

In SAP integration scenarios the Saga pattern is particularly valuable for the Lead-to-Cash process. A typical flow involves:

1. Create Sales Order in S/4HANA
2. Create Opportunity in C4C linked to the order
3. Trigger credit check via FSCM
4. Confirm order and notify customer

If the credit check in step 3 fails, the Saga must cancel the C4C opportunity (step 2) and reverse the S/4HANA sales order (step 1). Without a Saga, this requires manual intervention or a custom error-handling procedure in each system.

from("direct:lead-to-cash")
  .saga()
    .step()
      .to("direct:create-s4-sales-order")
      .compensation("direct:cancel-s4-sales-order")
    .step()
      .to("direct:create-c4c-opportunity")
      .compensation("direct:cancel-c4c-opportunity")
    .step()
      .to("direct:run-credit-check")
      // throws CreditLimitExceededException on failure
    .step()
      .to("direct:confirm-and-notify")
  .end();

Idempotency and the Saga Log

For production Sagas, two additional concerns are critical:

• Idempotency — each step and compensation must be safe to call more than once. Network retries can cause duplicate calls. Use idempotency keys (order IDs, correlation IDs) in every external API call.
• Saga log — persist the state of each Saga step so that a process restart can resume or roll back an in-flight Saga. Camel's InMemorySagaService is suitable for development; use LRACoordinator (MicroProfile LRA) or a custom JDBC-backed implementation for production.

The Saga pattern does not give you the simplicity of a database transaction, but it gives you something more valuable in a distributed system: explicit, auditable, compensatable business flows that remain consistent even under partial failure.