O que é o padrão Saga

In a microservices architecture, a single business operation often needs to interact with multiple independent services and their databases.

Traditional database transactions (known as ACID transactions) are great for ensuring consistency within a single database. However, they don't easily span across different services or databases.

Imagine an online purchase: an order is created, payment is processed, and inventory is updated. What if the payment succeeds but the inventory update fails?

Without a mechanism to coordinate these steps, your system could end up in an inconsistent state, like a customer paying for an item that's still in stock but not assigned to their order.

The Saga pattern is a way to manage business transactions that span multiple services, ensuring data consistency across them.

A Saga is a sequence of local transactions. Each local transaction updates data within a single service and publishes an event to trigger the next step in the Saga.

A local transaction is a standard, atomic database transaction that occurs entirely within a single microservice.

• It starts and commits (or rolls back) within the boundaries of that service's database.
• It ensures that the data within that specific service remains consistent.

The Saga coordinates these local transactions to achieve a larger, distributed business goal.

What happens if one of the local transactions in a Saga fails after previous steps have already committed?

The Saga pattern handles this by executing compensation transactions. A compensation transaction is designed to undo the effects of a previously completed local transaction.

Sagas differ from traditional ACID (Atomicity, Consistency, Isolation, Durability) transactions:

• ACID: All-or-nothing, immediate consistency, strong isolation.
• Saga: Achieves eventual consistency across services. It trades immediate atomicity for availability and scalability in distributed systems.

Sagas provide transactional integrity over time, even if not instantaneously atomic.

Sagas are particularly useful when:

• You need to maintain data consistency across multiple, independent microservices.
• You cannot use a distributed two-phase commit (which is often true in microservices).
• Your business processes are complex and span several system boundaries.

They help manage long-running, distributed business processes gracefully.

Let's consider a common e-commerce scenario: placing an online order.

This might involve several services:

• Order Service
• Payment Service
• Inventory Service
• Shipping Service

A Saga can coordinate the steps to ensure the entire process is completed successfully, or properly rolled back.

Here’s how an order Saga might flow:

1. Order Service: Creates the order (local transaction).
2. Payment Service: Processes the payment (local transaction).
3. Inventory Service: Reduces stock for the item (local transaction).
4. Shipping Service: Schedules shipment (local transaction).

If, for example, the Inventory Service fails to reduce stock, the Saga would trigger compensation for the Payment and Order Services.

You've learned that the Saga pattern helps manage distributed business transactions across multiple microservices.

• It's a sequence of local transactions, each atomic within its own service.
• It uses compensation transactions to undo previous steps if a later one fails.
• Sagas provide eventual consistency, making them ideal for complex, distributed processes where immediate ACID properties are not feasible.

Next, we'll explore different ways to implement Sagas: Choreography and Orchestration.