Saga Rollback Strategies: Compensate Without Distributed Locks (2026)

A saga is a sequence of local transactions, where each transaction updates data within a single service and publishes a message or event to trigger the next transaction in the saga. If any local transaction fails, the saga executes a series of compensating transactions to undo the preceding local transactions.

Let’s see a simple saga in action for an e-commerce order placement.

{
  "orderId": "ORD12345",
  "customerId": "CUST67890",
  "items": [
    {"productId": "PROD001", "quantity": 2},
    {"productId": "PROD002", "quantity": 1}
  ],
  "totalAmount": 150.75
}

1. Order Service: Receives the order.

   • Local Transaction: Creates an Order record in its database with status: PENDING.
   • Event Published: OrderCreated (containing order details).

2. Inventory Service: Listens for OrderCreated.

   • Local Transaction: Reserves items. Decrements quantity for PROD001 and PROD002. If successful, publishes ItemsReserved.
   • If ItemsReserved cannot be published (e.g., insufficient stock), it publishes ItemReservationFailed.

3. Payment Service: Listens for ItemsReserved.

   • Local Transaction: Charges the customer. Creates a Payment record with status: PAID. If successful, publishes PaymentProcessed.
   • If charging fails, it publishes PaymentFailed.

4. Order Service (again): Listens for PaymentProcessed or PaymentFailed.

   • If PaymentProcessed: Updates Order status to APPROVED.
   • If PaymentFailed: Updates Order status to FAILED.

Now, what happens if the PaymentService fails?

• The PaymentService publishes PaymentFailed.
• The OrderService listens for PaymentFailed and updates the order status to FAILED.
• But we’re not done. The ItemsReserved event is still in the message queue, and the InventoryService has reserved items. We need to compensate.

To compensate for the ItemsReserved event, the OrderService (or a dedicated saga orchestrator) would publish a CancelOrder event.

• Inventory Service (compensating): Listens for CancelOrder.
  • Compensating Transaction: Releases the reserved items. Increments quantity for PROD001 and PROD002. Publishes ItemsReleased.

This is where the "compensate without distributed locks" comes in. If the InventoryService tried to directly undo the ItemsReserved transaction by, say, calling a ReleaseItems API on the OrderService while the OrderService was still processing PaymentFailed, you could have race conditions.

The core problem is that a compensating transaction is not simply the inverse of a local transaction. A local transaction might succeed, but its effect (e.g., an item reservation) might need to be undone later due to a failure downstream. The compensation logic needs to be idempotent and handle the state of the system at the time it’s invoked.

Consider the OrderService receiving PaymentFailed. It needs to trigger compensation. It publishes CancelOrder. The InventoryService receives CancelOrder. Its local transaction was to reserve items. The compensating action is to release those items. If the InventoryService has already processed ItemsReserved and the compensation logic is triggered, it should simply execute the release.

What if the InventoryService receives CancelOrder before it successfully processes ItemsReserved? This is a critical point. The compensation must be robust. If the InventoryService receives CancelOrder when its internal state is still "awaiting reservation confirmation" (or similar), it should ideally ignore the CancelOrder or mark the reservation as "cancelled" without actually decrementing stock. The key is that the final state must reflect that the items were never truly committed to the order, even if the reservation technically happened.

A common pattern is to use the event itself as the trigger for compensation, and the compensating action is another event. The OrderService doesn’t directly tell InventoryService to "undo reservation." Instead, it says, "This order is cancelled" (CancelOrder event). The InventoryService then applies its compensation logic based on that event, which is to release any items it might have reserved for that order. The idempotency of the ItemsReserved and ItemsReleased operations is paramount here. If ItemsReleased is called twice for the same reservation, it should have no further effect after the first call. This is achieved by tracking the state of the reservation (e.g., reserved, released, cancelled).

The most surprising true thing about saga compensation is that the compensating transaction often doesn’t "undo" the previous transaction in a direct, atomic rollback sense. Instead, it performs a separate business operation that reverses the effect of the prior operation, and this reversal must be designed to be independent and potentially handle cases where the original operation may not have fully completed or committed.

The next concept you’ll likely encounter is how to manage the state of the saga itself when failures occur mid-compensation.