In a monolithic application, managing data consistency is straightforward. If you need to update several database tables at once, you can wrap the operations in a single transaction. This is often called an ACID transaction (Atomicity, Consistency, Isolation, Durability). If any step fails, the entire transaction is rolled back, and the database returns to its original state. Nothing is left half-done.

But in a distributed architecture, like one using microservices, things get complicated. Each microservice typically owns its own data and database. An operation like placing an online order might involve several services: an Order service, a Payment service, and an Inventory service. You can't just stretch a single database transaction across these separate services. They are independent and need to remain loosely coupled.

The Saga pattern offers a solution. Instead of a single, all-or-nothing distributed transaction, a saga breaks a business process down into a sequence of local transactions. Each local transaction is handled by a single service and updates that service's own database.

The key to a saga is how it handles failure. For every step in the sequence, there is a corresponding compensating transaction. If any local transaction fails, the saga executes the compensating transactions for all the preceding steps that succeeded. This effectively undoes the completed work, leaving the system in a consistent state.

Imagine booking a trip. This involves booking a flight, a hotel, and a rental car. In a saga, this would be three separate local transactions:

1. Book Flight: The Travel service talks to the Flight service.
2. Book Hotel: The Travel service talks to the Hotel service.
3. Book Car: The Travel service talks to the Car Rental service.

What happens if the flight and hotel are booked successfully, but the car rental fails? The saga initiates compensating transactions to cancel the hotel and then the flight, in reverse order. The end result is that no part of the trip is booked, and the customer isn't charged.

Sagas do not provide the immediate, atomic consistency of a traditional ACID transaction. Instead, they provide eventual consistency. This means that for a short period, the system might be in an inconsistent state. In our trip booking example, the flight might be booked for a few moments before the car rental fails and the flight is subsequently canceled.

The system is guaranteed to become consistent eventually, once the saga completes either successfully or by running all necessary compensating transactions. This trade-off is fundamental to building scalable and resilient distributed systems. By giving up immediate consistency, we gain higher availability and performance because services don't have to wait on each other to lock resources.

Before you dive deeper into how Sagas are implemented, let's review the core concepts.

Time to check your understanding.

The Saga pattern is a powerful technique for maintaining data consistency in complex, distributed systems without sacrificing the autonomy and scalability that make microservices so appealing.