What is a compensating transaction?

A compensating transaction undoes the effect of a previous step in a saga. For example, if "charge payment" succeeded but "reserve inventory" failed, the compensating transaction for the payment step is "issue refund." Every saga step must have a defined compensating action.

Should I use choreography or orchestration for sagas?

Orchestration for complex sagas (4+ steps) because the logic is centralized and easier to understand. Choreography for simple sagas (2-3 steps) where the decentralized event-driven approach keeps services loosely coupled.

The Saga Pattern Explained

Managing distributed transactions across microservices with compensating actions — no two-phase commit required.

Saga Pattern

The saga pattern is a design pattern for managing distributed transactions across multiple services. Instead of a single ACID transaction spanning services, a saga breaks the transaction into a series of local transactions, each with a compensating action that undoes its effect if a later step fails.

Explanation

In a monolithic application, a database transaction ensures atomicity: either all operations succeed or all are rolled back. In a microservices architecture, a single business operation (like placing an order) may span multiple services — Order Service, Payment Service, Inventory Service, Shipping Service. A traditional distributed transaction (two-phase commit) is slow, brittle, and requires all services to be available simultaneously. The saga pattern replaces distributed transactions with a sequence of local transactions. Each service performs its operation and publishes an event. If all steps succeed, the saga completes. If any step fails, the saga executes compensating transactions for all previously completed steps — reversing their effects. For example: if payment succeeds but inventory reservation fails, the saga triggers a payment refund. There are two saga coordination styles: choreography (each service listens for events and decides what to do next — decentralized but hard to follow) and orchestration (a central saga orchestrator tells each service what to do — centralized, easier to understand, but introduces a single point of coordination). The orchestration pattern is generally preferred for complex sagas because the logic is in one place rather than scattered across services.

Bookuvai Implementation

Bookuvai uses the saga pattern for complex multi-service operations like order processing, subscription management, and payment workflows. We prefer the orchestration approach with a dedicated saga coordinator service that manages the workflow, tracks state, and handles compensation on failure. Saga state is persisted to ensure recovery after service restarts. This architecture is designed during the technical milestone and tested extensively during integration testing.

Key Facts

Replaces distributed transactions with local transactions + compensating actions
Orchestration (central coordinator) is easier to understand than choreography (event-driven)
Every step must have a compensating action for rollback on failure

Related Terms

Frequently Asked Questions

What is a compensating transaction?: A compensating transaction undoes the effect of a previous step in a saga. For example, if "charge payment" succeeded but "reserve inventory" failed, the compensating transaction for the payment step is "issue refund." Every saga step must have a defined compensating action.
Should I use choreography or orchestration for sagas?: Orchestration for complex sagas (4+ steps) because the logic is centralized and easier to understand. Choreography for simple sagas (2-3 steps) where the decentralized event-driven approach keeps services loosely coupled.