Saga Pattern in Microservices: An In-depth Overview

[akash-coded]

Saga Pattern in Microservices: An In-depth Overview

What is the Saga Pattern?

When you shift from a monolithic to a microservices architecture, one of the first challenges you face is maintaining data consistency across services. In a monolithic system, you'd simply use a transaction. In microservices, due to the distributed nature, this isn't straightforward. That's where the saga pattern comes in.

A saga is a sequence of local transactions. Each transaction updates data within a single service and publishes an event to trigger the next transaction in the saga. If one transaction fails, the saga executes compensating transactions to undo the impact of the preceding transactions.

Why Use the Saga Pattern?

• Maintaining Data Consistency: Microservices should be loosely coupled and have their own databases. Saga helps maintain consistency across these databases.

• Long-Running Transactions: Some operations are inherently long-running. You don't want to lock resources for the entire duration. Saga offers a solution.

Types of Saga Patterns:

1. Choreography: Every local transaction publishes domain events. Other local transactions consume those events and execute, potentially emitting new events.

2. Orchestration: One service (the coordinator) is in charge of directing the saga. It tells other services to execute local transactions.

Advantages:

• Resilience: Failure in one service doesn't bring down other services.

• Loose Coupling: Services act based on events, not direct requests from other services.

• Scalability: Asynchronous nature of sagas allows for better scalability.

Disadvantages:

• Complexity: Implementing sagas can be complex due to compensating transactions and coordination.

• Debugging and Tracing: A saga's asynchronous and potentially distributed nature can make debugging more challenging.

Alternatives:

• Two-Phase Commit (2PC): A coordinator ensures all services commit or rollback. However, this is not recommended due to its blocking nature and single point of failure.

Implementing Saga in Spring Boot:

For this, we'll use an example of an e-commerce platform where an order placement involves: checking stock, deducting stock, charging payment, and notifying the user.

1. Service Setup:

Imagine four services: OrderService, InventoryService, PaymentService, and NotificationService.

2. Saga Flow:

• OrderService receives a request to place an order.
• It checks with InventoryService if the stock is available.
• If yes, InventoryService deducts the stock and emits a StockDeductedEvent.
• PaymentService listens to StockDeductedEvent, charges the payment, and emits a PaymentChargedEvent.
• NotificationService listens to PaymentChargedEvent and notifies the user.

3. Implementing with Spring Boot and Kafka:

• You'll use Spring Cloud Stream for communicating between services via Kafka topics.

// In InventoryService
@StreamListener(target = Sink.INPUT, condition = "headers['type']=='OrderPlacedEvent'")
public void handleOrderPlacedEvent(OrderPlacedEvent event) {
    if (isStockAvailable(event)) {
        deductStock(event);
        eventPublisher.publishEvent(new StockDeductedEvent(event.getOrderId()));
    } else {
        // emit a compensating event or handle accordingly
    }
}

// In PaymentService
@StreamListener(target = Sink.INPUT, condition = "headers['type']=='StockDeductedEvent'")
public void handleStockDeductedEvent(StockDeductedEvent event) {
    chargePayment(event);
    eventPublisher.publishEvent(new PaymentChargedEvent(event.getOrderId()));
}

// Similar patterns for other services.

Compensating Transactions:

For any failure, compensating actions must be triggered. For instance, if the payment fails, the stock should be reverted.

Best Practices:

• Idempotency: Ensure operations can be retried without adverse effects.

• Logging and Monitoring: Given the complexity of sagas, strong logging and monitoring are crucial.

• Event Versioning: If the structure of an event changes, it can break services. Version your events to handle changes gracefully.

Summary:

The saga pattern is a potent remedy for data consistency woes in microservices but comes with its own challenges. Properly implemented, it can bring resilience and scalability to your distributed system, ensuring a harmonious symphony of collaborating services in the microservices world.

---

Let's further explore the practical intricacies of the Saga Pattern, particularly when diving into a Spring Boot application.

Transaction Boundaries in Sagas:

The Saga pattern challenges the traditional way we think about transactions, especially in a microservice architecture. Each step in a saga performs its own local transaction, which then triggers the next step. If any step fails, compensating transactions in previously successful steps can be initiated.

Saga Coordination Types in Spring:

1. Choreography:

   • Each local transaction publishes domain events to which other local transactions subscribe.
   • Event-driven: Spring Cloud Stream with RabbitMQ/Kafka can be used.
   • No centralized service orchestrating the flow. Every service decides the next step based on the events.

2. Orchestration:

   • An orchestrator (central service) determines the order of transactions.
   • Can use Spring Cloud Orchestrator.
   • Command-driven: The orchestrator tells the participants what local transaction to execute.

Saga Implementations with Spring:

Choreography-based Saga with Kafka:

Kafka’s topic and partitioning mechanism naturally fits with domain events.

1. Use Spring Cloud Stream's Kafka binder.
2. Define Kafka topics for domain events.
3. Use Kafka’s exactly-once semantics to ensure reliable event publishing.
4. Design each service to be idempotent, enabling them to safely retry operations.

Orchestration-based Saga with RESTful API calls:

1. The orchestrator can be a Spring Boot application.
2. Use Spring's RestTemplate or Feign clients to make synchronous HTTP calls.
3. Ensure idempotency: Assign a unique ID for each saga. Services can check if they have already seen the saga ID and ignore duplicate requests.

Compensating Transactions:

1. When an operation fails, initiate a compensating transaction to undo changes.
2. For example, in a createOrder saga, if payment processing fails, a compensating transaction can cancel the order.

Saga Persistence:

1. Event Sourcing:

   • Store each domain event.
   • The current state is derived by replaying these events.
   • Can use Spring Boot with Axon framework.

2. Command Model:

   • Store the current state.
   • Use traditional CRUD operations.

Saga Execution and Query Consistency:

1. Eventual Consistency:

   • Sagas do not provide immediate consistency.
   • Over time, all replicas become consistent.

2. Commands and Queries:

   • Separate models for write (command) and read (query) to address the eventual consistency.
   • Spring's CQRS support can be leveraged.

Saga Rollback Mechanism:

1. Manual Rollback: Implement rollback mechanisms in each service for compensating transactions.
2. Event-based Rollback: Upon failure, emit a failure event that other services listen to, triggering compensating transactions.

Best Practices:

1. Idempotence: Always design services to be idempotent.
2. Timeouts: Implement timeouts for saga steps to avoid waiting indefinitely.
3. Monitoring & Alerts: Utilize Spring Boot Actuator, Prometheus, Grafana to monitor saga execution and set alerts for failures.

---

Let's delve deeper into the orchestration approach of the saga pattern and then illustrate it with an example for our e-commerce platform.

Saga Pattern - Orchestration Approach:

In the orchestration style, one service (often referred to as the 'saga orchestrator' or 'coordinator') takes charge of the saga's progress. It knows the order of steps, which service to call, and what to do in case of failures.

Pros:

1. Centralized Control: Having a single orchestrator provides a more straightforward view of the saga's business logic.
2. Easier Compensating Transactions: Since the orchestrator knows the sequence of events, it can easily initiate compensating actions in case of failures.

Cons:

1. Single Point of Failure: If the orchestrator fails, the saga can't proceed.
2. Potential Bottleneck: The orchestrator might become a performance bottleneck if not designed carefully.

Orchestration in Action:

Considering our e-commerce platform, let's use an orchestration approach:

1. OrderService acts as the saga orchestrator.

2. A customer places an order, and the saga begins.

3. OrderService asks InventoryService to check and reserve stock.

   • If stock isn't available, OrderService responds to the customer about the stock unavailability and the saga ends.

4. If the stock is reserved successfully, OrderService then asks PaymentService to charge the customer.

   • If payment fails, OrderService tells InventoryService to release the reserved stock. The customer is informed of the payment failure, and the saga ends.

5. With payment successful, OrderService instructs NotificationService to notify the customer of the order's success.

This entire process is choreographed by the OrderService. Each step's outcome determines the next service to call.

Implementing Orchestration with Spring Boot:

Here, we will use Spring WebFlux to make asynchronous, non-blocking calls to services.

@RestController
@RequestMapping("/orders")
public class OrderController {

    @Autowired
    private InventoryServiceClient inventoryServiceClient;
    
    @Autowired
    private PaymentServiceClient paymentServiceClient;
    
    @Autowired
    private NotificationServiceClient notificationServiceClient;

    @PostMapping
    public Mono<ResponseEntity> placeOrder(@RequestBody Order order) {
        return inventoryServiceClient.checkAndReserveStock(order.getProductId())
                .flatMap(stockResponse -> {
                    if (stockResponse.isSuccessful()) {
                        return paymentServiceClient.chargePayment(order.getUserId(), order.getAmount())
                                .flatMap(paymentResponse -> {
                                    if (paymentResponse.isSuccessful()) {
                                        return notificationServiceClient.notifyUser(order.getUserId())
                                                .map(notificationResponse -> ResponseEntity.ok().build());
                                    } else {
                                        inventoryServiceClient.releaseStock(order.getProductId());
                                        return Mono.just(ResponseEntity.status(HttpStatus.PAYMENT_REQUIRED).build());
                                    }
                                });
                    } else {
                        return Mono.just(ResponseEntity.status(HttpStatus.NOT_FOUND).build());
                    }
                });
    }
}

Note: This is a simplistic representation. In real-world scenarios, you'd handle timeouts, fallbacks, and potential failures more gracefully.

Summary:

The saga pattern, when orchestrated, can provide a clear view of the business logic. However, it comes with its own set of challenges, primarily the potential bottleneck and single point of failure. Proper design, asynchronous calls, and fallback mechanisms can help mitigate these challenges and craft a robust microservices environment.

---

Let's dive deeper into the Choreography approach of the saga pattern, how it differs from Orchestration, and then illustrate it with an example in the context of our e-commerce platform.

Saga Pattern - Choreography Approach:

In the choreography style, there isn't a central orchestrator that tells participants what to do. Instead, each service involved in the saga knows about its own local transaction and knows when to execute it. It also knows which event it needs to publish when it has finished its local transaction.

Pros:

1. Decentralized Control: Each service is independent and only aware of its own business logic.
2. Resilience: There's no single point of failure. Even if one service fails, other services can continue their operations.
3. Scalability: Independent nature allows for better scalability since there's no bottleneck.

Cons:

1. Complexity: It might be harder to see the overall flow of the saga since it's distributed among services.
2. Data Consistency: Ensuring data consistency across services can be more challenging without centralized control.

Choreography in Action:

Taking our e-commerce scenario:

1. A customer places an order in OrderService.

2. OrderService saves the order and emits an OrderPlacedEvent.

3. InventoryService listens for OrderPlacedEvent, and once it catches this event, it checks and reserves the stock. If stock is reserved successfully, it emits a StockReservedEvent.

   • If stock isn't available, it emits a StockUnavailableEvent.

4. PaymentService listens for StockReservedEvent. Once it catches this event, it charges the customer.

   • If payment is successful, it emits a PaymentSuccessEvent.
   • If payment fails, it emits a PaymentFailedEvent.

5. OrderService listens for PaymentSuccessEvent and PaymentFailedEvent to update the order status accordingly.

6. NotificationService listens to various events to notify the customer at different stages.

Implementing Choreography with Spring Boot:

For this, we'll use Spring Cloud Stream – a framework for building message-driven microservices.

1. Setting up Spring Cloud Stream:

For each service, you'd include the following dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-kafka</artifactId>
</dependency>

2. Publishing Events:

Using OrderService as an example:

@EnableBinding(Source.class)
public class OrderService {

    @Autowired
    private Source source;

    public void placeOrder(Order order) {
        // ... save order logic
        source.output().send(MessageBuilder.withPayload(new OrderPlacedEvent(order.getId())).build());
    }
}

3. Listening to Events:

In InventoryService:

@EnableBinding(Sink.class)
public class InventoryService {

    @StreamListener(target = Sink.INPUT)
    public void handleOrderPlacedEvent(OrderPlacedEvent event) {
        // ... check and reserve stock logic
    }
}

4. Configuring Kafka (or any other broker):

In application.properties:

spring.cloud.stream.kafka.binder.brokers=YOUR_KAFKA_BROKER_ADDRESS
spring.cloud.stream.bindings.input.destination=orders
spring.cloud.stream.bindings.output.destination=stocks

This setup allows services to listen and react to events. When an event occurs in one service, other services that are subscribed to that event will automatically pick it up and process it accordingly.

Summary:

The choreographed saga pattern can seem more complex initially due to its distributed nature, but it offers more flexibility and scalability. It fits nicely in scenarios where you have a lot of services and you want to avoid making any one of them a potential bottleneck or single point of failure. The key is to carefully design your events and make sure each service knows how to handle them correctly.

We'll progress by examining the challenges with choreography, and subsequently, we'll explore advanced features and concepts associated with sagas and Spring Cloud Stream.

Challenges with Choreography in Sagas:

1. Event Propagation Delays: In a distributed system, events might not be instantaneous. An event from one service might be delayed due to network issues, causing another service to potentially make decisions on stale data.

2. Event Versioning: As your system evolves, so does the structure of your events. Managing different versions of events and ensuring backward compatibility can be challenging.

3. Event Tracking: Since there's no central orchestrator, monitoring which services have handled which events can become challenging.

4. Event Reliability: Ensuring that events are delivered at least once, and preferably only once, is a significant challenge.

Advanced Features with Spring Cloud Stream:

1. Consumer Groups:

   • They allow multiple instances of an application to divide the message load.
   • Imagine two instances of PaymentService. Without consumer groups, both instances would get all the messages, leading to redundancy. With consumer groups, you can ensure each message is processed by only one instance.

2. Stateful Processing:

   • By utilizing features like windowing or session windows, you can perform operations based on events over a period of time. Useful for features like "User has made 3 failed payment attempts in the last 10 minutes".

3. Interactive Queries:

   • Spring Cloud Stream provides the ability to query your application about its current state. Useful for understanding the current state of a saga, for example.

Choreography with Multiple Brokers:

It's also possible to utilize multiple brokers for different parts of the system. For instance, you might use Kafka for long-lived, durable events, while using RabbitMQ for real-time, short-lived notifications.

Saga with Choreography: Compound Scenario:

Imagine a user trying to book a holiday package.

1. BookingService (Central point to start the booking):

   • User initiates the holiday booking, and BookingService emits a HolidayBookingStartedEvent.

2. FlightService:

   • Listens for HolidayBookingStartedEvent.
   • Tries to book a flight.
   • If successful, emits FlightBookingConfirmedEvent.
   • If failed, emits FlightBookingFailedEvent.

3. HotelService:

   • Listens for FlightBookingConfirmedEvent.
   • Tries to book a hotel.
   • If successful, emits HotelBookingConfirmedEvent.
   • If failed, emits HotelBookingFailedEvent.

4. PaymentService:

   • Listens for HotelBookingConfirmedEvent.
   • Attempts to charge the user.
   • If successful, emits PaymentSuccessEvent.
   • If failed, emits PaymentFailedEvent, causing both FlightService and HotelService to rollback.

5. NotificationService:

   • Listens to success or failure events from any service to notify the user accordingly.

This approach ensures that each service reacts to events and takes appropriate actions. The benefits include high decoupling and scalability. The challenge is ensuring reliability and managing failures gracefully.

Conclusion:

Choreography-based sagas, especially in Spring Boot microservices architecture, can provide scalability and flexibility benefits. However, understanding and designing the event flow is crucial. Employing Spring Cloud Stream features can further enhance and refine the way events are processed, making the system robust and efficient. It's always vital to choose between orchestration and choreography based on the nature and requirements of the application.

---

The saga pattern inherently requires mechanisms to handle failures since distributed transactions are not atomic. If one step fails, we can't just roll back like in traditional ACID transactions. Instead, we use compensating transactions.

Saga Rollback Mechanism:

When we speak of a "rollback" in the context of sagas, it doesn't mean the same thing as a traditional database rollback. Instead, it means performing a compensating action that effectively undoes a previous action.

Compensating Transactions:

These are the heart of the saga rollback mechanism. For every transaction that modifies the system's state, there must be a corresponding compensating transaction that can reverse that modification.

For instance:

• If the action is "debit account," the compensating action might be "credit account."
• If the action is "reserve product in inventory," the compensating action might be "release product reservation."

Scenario 1: E-commerce Order Failure

Imagine an e-commerce platform that has a three-step saga for processing orders:

1. Reserve the product in inventory.
2. Debit the customer's credit account.
3. Ship the product.

If the debit operation fails (maybe due to insufficient funds), we can't ship the product, but we've already reserved it in step 1. In this scenario, the compensating action for the reservation would trigger, releasing the product back to the inventory.

Scenario 2: Travel Booking System

Consider a travel booking system where a user wants to book a flight, hotel, and rent a car:

1. Book the flight.
2. Reserve the hotel room.
3. Book the car rental.

Suppose the car rental service is down. In the saga pattern, the system will then execute compensating transactions: cancel the hotel room and flight booking. Thus, even if part of the operation fails, the user isn't left with partial reservations.

Challenges and Considerations:

1. Idempotence: Your compensating transactions need to be idempotent. Executing them multiple times shouldn't have a different effect than executing them once.

2. Network Failures: What if the service responsible for the compensating transaction is down or unreachable? You might need to implement a retry mechanism or a manual intervention procedure.

3. Data Consistency: While the saga pattern aims to maintain data consistency across services, there's a period where data is inconsistent until the saga completes or the compensating transactions execute.

4. Complexity: With sagas, you are trading off simplicity for scalability and flexibility. Instead of a single ACID transaction, you now have multiple transactions, each with their own compensating transactions.

Implementation using Spring Boot:

Spring doesn't offer out-of-the-box support for sagas, but you can combine several of its features to implement them:

1. Event Sourcing: Use Spring Kafka or RabbitMQ to produce events that represent state changes. If a failure occurs, produce compensating events.

2. Spring Cloud Stream: This can be used to handle the communication between microservices in an event-driven manner.

3. Database Per Service: Maintain data consistency within each service's boundary using traditional transactions. The overall consistency is maintained through sagas.

4. Orchestrator vs. Choreography: You can implement sagas using an orchestrating service that guides other services through the saga steps, or you can use a choreographed approach where every service knows its next step and possible compensations.

The heart of the Saga pattern lies in its compensating transactions. Each compensating transaction is essentially the 'undo' operation for a preceding successful operation. To explore this in-depth, let's start with some simpler scenarios and then build up to more complex, intertwined use cases.

1. Basic Scenario: E-commerce Order Placement

Services: InventoryService, OrderService, PaymentService, NotificationService

Flow:

1. User places an order.
2. OrderService creates an order.
3. PaymentService charges the user.
4. InventoryService reduces the item count.
5. NotificationService sends an order confirmation to the user.

Compensating Transactions:

• If payment fails, the order is canceled (OrderService).
• If inventory reduction fails (maybe item got out of stock), refund the user (PaymentService) and cancel the order.
• If notification fails (a less critical failure), log it for manual intervention but don’t roll back the order.

Deep Dive into Rollback Mechanism:

Let's focus on the InventoryService failing. What happens behind the scenes?

a. InventoryService fails:

• It publishes an "InventoryFailureEvent" on a message broker topic (like Kafka or RabbitMQ).

b. PaymentService listens to this:

• It has a listener for InventoryFailureEvent.
• When it gets the event, it initiates a refund.
• Once the refund is successful, it publishes a "PaymentRefundedEvent".

c. OrderService listens to PaymentRefundedEvent:

• It has a listener set up for this event.
• On receiving the event, it cancels the order and logs the reason.

The above actions might appear straightforward, but remember, each of those steps could fail as well. What if PaymentService couldn’t process the refund? You need mechanisms to retry, notify admins, or even manually intervene.

2. Compound Scenario: Interdependent Services in a Financial App

Services: AccountService, TransferService, AuditService, NotificationService

Flow:

1. User initiates a funds transfer.
2. TransferService initiates the transfer.
3. AccountService debits the source account and credits the target account.
4. AuditService logs the transfer.
5. NotificationService sends notifications to both sender and receiver.

Compensating Transactions:

• If credit fails (target account doesn't exist or is frozen), rollback the debit from the source account and fail the transfer.
• If audit logging fails (a critical failure in financial apps), roll back both credit and debit actions, effectively nullifying the transfer.
• Notification failures can be retried or logged for manual intervention.

Deep Dive into the Compound Rollback Mechanism:

a. AuditService fails:

• It notifies the TransferService about the failure.
• TransferService then sends commands to AccountService to undo both credit and debit actions.
• After the above rollback, it sends notifications to both users about the failure (NotificationService).

b. Complex Rollbacks:
In systems where operations aren’t merely opposites of one another, compensating transactions might involve complex logic. For instance, if an e-commerce price discount applied after a certain operation gets rolled back, compensating might mean recalculating the whole cart.

c. Manual Interventions:
Sometimes, it might be more logical to manually correct a failure, especially when human judgment is needed.

Compensating Transactions in Distributed Databases

While we've mostly discussed compensating transactions in terms of business logic, the same principles can apply at the database level. Distributed databases, which might span across regions or data centers, can use sagas to ensure consistency across nodes.

In case of a node failure or network partition, compensating transactions can ensure data remains consistent across all active nodes. This is especially prevalent in databases that value availability over immediate consistency (AP systems in the CAP theorem).

Summary:

In the saga pattern, events play a significant role, not only in driving forward the business process but also in driving backward (rolling back) when a compensating action is needed. Implementing Saga requires careful design, considering all possible failure scenarios, and ensuring that the system can either recover automatically or provide means for manual recovery. Proper logging, monitoring, and alerting become more crucial than ever.

Also, while REST or RPC can be used for synchronous inter-service communication, the async nature of event-driven mechanisms (like Kafka, RabbitMQ) aligns better with the Saga pattern, especially with its compensatory actions.

Lastly, while Sagas help maintain data consistency across services, they introduce eventual consistency into the system. This is a trade-off: you get autonomy and isolated failures, but it comes at the expense of the immediate consistency that a monolithic system might offer.

[akash-coded]

Let's take the Travel Booking System scenario for an in-depth breakdown and implementation.

System Architecture

Microservices:

1. FlightBookingService
2. HotelBookingService
3. CarRentalService
4. BookingOrchestratorService (Orchestrator for the Saga)

Implementation Steps:

Step 1: Setup Spring Boot Microservices.

Use Spring Initializr or your IDE to create Spring Boot applications for each of the services.

Step 2: Configure Data Source and JPA

This step is pretty standard for each service. Since we're using H2, each service would have configurations in their application.properties similar to:

spring.datasource.url=jdbc:h2:mem:flightdb
spring.datasource.driver-class-name=org.h2.Driver
spring.jpa.hibernate.ddl-auto=update

(The datasource URL differs per service)

Step 3: Design Entities

• FlightBookingService:

  @Entity
  public class FlightBooking {
      @Id
      @GeneratedValue
      private Long id;
      private String userId;
      private String flightNumber;
      // ... other fields, getters, setters
  }

• HotelBookingService:

  @Entity
  public class HotelBooking {
      @Id
      @GeneratedValue
      private Long id;
      private String userId;
      private String hotelName;
      // ... other fields, getters, setters
  }

• CarRentalService:

  @Entity
  public class CarRental {
      @Id
      @GeneratedValue
      private Long id;
      private String userId;
      private String carModel;
      // ... other fields, getters, setters
  }

Step 4: Design Repositories

For each entity, create a CrudRepository. Example for FlightBooking:

public interface FlightBookingRepository extends CrudRepository<FlightBooking, Long> {
    Optional<FlightBooking> findByUserId(String userId);
}

Step 5: Implement Business Logic

This is where it gets interesting. The main business logic of each service is to manage its respective bookings. However, if one service fails to book, it should trigger a compensating transaction to "undo" the bookings made by the previous services.

Example: If CarRentalService fails, it should notify HotelBookingService and FlightBookingService to cancel their respective bookings.

Step 6: Introduce Messaging for Inter-service Communication

We use Spring Cloud Stream with RabbitMQ/Kafka. Here's a brief setup:

1. Add dependencies for Spring Cloud Stream and the binder of choice (RabbitMQ/Kafka).
2. Define channels for communication.

Example for HotelBookingService:

public interface HotelBookingChannels {
    @Input("cancelHotelBookingChannel")
    SubscribableChannel cancelHotelBooking();
}

3. Listen to the channel and execute compensating transactions.

@EnableBinding(HotelBookingChannels.class)
public class HotelBookingListener {

    @Autowired
    private HotelBookingRepository repository;

    @StreamListener("cancelHotelBookingChannel")
    public void listenForCancelBooking(String userId) {
        // Logic to cancel booking
    }
}

Step 7: Implement the Orchestrator

BookingOrchestratorService coordinates the steps of the saga. It calls each service in sequence, checks the response, and decides whether to proceed or to start compensating transactions.

Step 8: Handle Failures and Compensation

Whenever a service detects a failure, it sends a message to the RabbitMQ/Kafka topic that the other services are listening to. Those services then start their compensating transactions based on the message.

Conclusion:

The Saga pattern introduces a different way of thinking about system reliability. Instead of relying on a centralized transaction manager to keep everything in sync, each service in a saga is responsible for its local transaction and for participating in ensuring the system as a whole remains consistent. This requires a shift in mindset and can be more complex to implement, but offers the advantage of long-running, flexible, and collaborative transactions.

[jay4tech]

Hi @akash-coded
Name: Jay Prakash Kumar

https://github.com/jay4tech/order-service-saga/tree/msa_171
https://github.com/jay4tech/inventory-service-rabbitmq/tree/msa_171
https://github.com/jay4tech/payment-service-saga/tree/msa_171
https://github.com/jay4tech/notification-service/tree/msa_171

[jay4tech]

Hi @akash-coded
Name: Jay Prakash Kumar

Part 2
https://github.com/jay4tech/order-service-saga/tree/msa_171_part_2
https://github.com/jay4tech/inventory-service-rabbitmq/tree/msa_171
https://github.com/jay4tech/payment-service-saga/tree/msa_171_part_2
https://github.com/jay4tech/notification-service/tree/msa_171

[arghyagiri]

@akash-coded : https://github.com/arghyagiri/microservice-e2/blob/main/e-commerce-microservices-event-driven-saga/Read.md

[AnuragMishra58]

Hi @akash-coded
Please find below github link for the Saga pattern task with screenshots:-
Emp Id: 550966
https://github.com/AnuragMishra58/microservices/blob/main/saga-pattern/Readme.md