รูปแบบ Saga ด้วย RabbitMQ

In microservices, a single business operation often spans multiple services. For example, placing an order might involve an Order Service, Inventory Service, and Payment Service.

A distributed transaction ensures that all these separate operations either succeed together or fail together, maintaining data consistency across your system.

Traditional database transactions often use a Two-Phase Commit (2PC) protocol to ensure atomicity. However, 2PC isn't ideal for microservices because:

• It creates tight coupling between services.
• It can lead to long-held locks, impacting availability.
• It's complex to implement and manage across different technologies.

We need a more flexible approach for distributed systems.

The Saga pattern is a way to manage distributed transactions. Instead of a single atomic transaction, a saga is a sequence of local transactions, each updating its own service's database.

• Each local transaction publishes an event upon completion.
• These events trigger the next step in the saga.
• If a step fails, compensating transactions are used to undo previous successful steps.

The goal is eventual consistency.

There are two main ways to implement a Saga:

• Orchestration: A central "Saga Orchestrator" service manages and directs the workflow, telling each participant what to do next.
• Choreography: Each service produces and listens to events, deciding its own next action without a central coordinator.

For this lesson, we'll focus on the Orchestration approach, which often pairs well with message brokers like RabbitMQ.

The Saga Orchestrator is a dedicated service responsible for:

• Receiving the initial command (e.g., "Create Order").
• Sending commands to saga participants (microservices).
• Listening for events from participants.
• Maintaining the saga's state.
• Deciding the next step or initiating compensating transactions if a step fails.

RabbitMQ is perfect for the orchestrator to send commands and receive events.

A Saga Participant is a microservice involved in the distributed transaction. When it receives a command from the orchestrator, it:

1. Performs its own local ACID transaction.
2. Updates its database.
3. Publishes an event (e.g., "OrderCreatedEvent", "StockReservedEvent") indicating success or failure.

These events are crucial for the orchestrator to continue the saga.

What happens if a step in the saga fails? This is where compensating transactions come in. They are operations designed to reverse the effects of previously completed local transactions.

For example, if a "Process Payment" step fails, a compensating transaction for "Reserve Stock" might be to release the reserved items back into inventory.

This ensures the system returns to a consistent state, even if not fully rolled back.

Let's imagine an order creation saga. The orchestrator receives a request and sends a command to the first participant (e.g., "Order Service"). Here's a simplified Java example:

Now, let's look at the "Order Service" (a participant) receiving the command. It processes the order locally and then publishes an event.

The orchestrator listens for events like OrderCreatedEvent. Upon receiving it, it updates the saga's state and sends the next command, perhaps to an "Inventory Service" to reserve stock.

Which of the following are key components or characteristics of the Saga Orchestration pattern?

The Saga pattern is a powerful way to manage complex, long-running distributed transactions in microservice architectures.

• It enables eventual consistency without tight coupling.
• It uses local transactions and compensating transactions for resilience.
• RabbitMQ provides the perfect backbone for the orchestrator and participants to communicate reliably through commands and events.

While adding complexity, Sagas are essential for building robust distributed systems.