How to use Saga Pattern with Spring Boot?
Introduction to Saga Pattern with Spring Boot.
A microservice is a distributed system made up of numerous smaller services that work together to offer overall application functionality. [1]
Although this architectural style has many advantages, it also has some drawbacks. One of the biggest issues is determining how to manage a transaction that involves numerous services. [1]
While the transaction spans numerous services in a distributed transaction scenario, maintaining ACID (atomicity, consistency, isolation, and durability) is always critical. The second difficulty is controlling the transaction isolation level. It determines the quantity of data visible in a transaction when other services access the same data at the same time. [1]
Two Phase Commiting Protocol (2PC)
2PC is a popular method for implementing distributed transactions. There is a coordinator component that is in charge of controlling the transaction and containing the transaction logic. The participating nodes, which perform their local transactions, are the other component. [1]
There are two phases. In phase one, the coordinator asks the participating nodes if they are ready to commit the transaction and waits for a yes or no response. If all nodes replied yes in phase 1, the coordinator instructs all nodes to commit; otherwise, the coordinator instructs all nodes to roll back. [1]
The downsides of 2pc protocols are as follows[1]:
- The coordinator is responsible for all services, which might lead to a single point of failure. [1]
- Because the controller determines when all services are completed, the entire performance of the operation is bound to the slowest service. [1]
- NoSQL databases do not support 2pc. [1]
Saga Architecture Pattern
The Saga architectural pattern manages transactions through a series of local transactions. After successfully completing the previous phase, the Saga Pattern triggers the next step with the incoming request. [1]
A Saga participant’s work is represented by a local transaction. Every operation in the Saga can be reversed by a compensatory transaction. A compensatory transaction must be reversible and idempotent. [1]
The Saga Execution Coordinator
The Saga Execution Coordinator is the key component in putting a Saga flow into action. It includes a Saga log, which records the sequence of events in a distributed transaction. [1]
In the event of a failure, the SEC component examines the Saga log to determine which components are affected and the order in which compensating transactions should be executed. [1]
If there is a failure in the SEC component, it can read the Saga log when it restarts. It can then determine which transactions were successfully rolled back and which are still pending, and take appropriate action. [1]
The Saga pattern can be implemented in two ways: choreography and orchestration.
Saga Orchestration Pattern
Microservices are controlled by an orchestrator or conductor. This allows centralized control of the saga or workflow. The orchestrator or conductor could be centralized for all the sagas or workflows or could be distributed as individual services for each saga or workflow. This provides varying levels of independence to each microservice.
The Saga Orchestration Pattern’s Benefits[2]:
- Centralizes the handling of scattered transactions. [2]
- Simple to set up and test. [2]
- Easy rollback administration. [2]
- As new steps are added, the process becomes less complex than the choreographic technique. [2]
- You have the ability to manage pending transactions. [2]
The Saga Orchestration Pattern’s Drawbacks[2]:
- The complexity of your infrastructure grows when you manage an additional saga orchestrator service. [2]
Saga Choreography Pattern
Microservices work independently but coordinate with each other using cues or events. The method of control of the saga or workflow is determined by a predefined set of cues or events.
Saga Choreography Pattern Benefits as follows [2]:
- Simple to understand and install into an existing system because the services that trigger the event are distinct from each other. [2]
- It can be quite useful if your procedure has two to four steps. [2]
Saga Choreography Pattern Drawbacks are as follows [2]:
- However, keeping track of which service is listening to which events can grow more complex as the flow becomes more complex.[2]
- As services must subscribe to one another, there may be cyclical dependencies. [2]
- Testing is tough since all services must be operational in order to thoroughly test the system. [2]
The Axon Saga framework can be used to implement Saga patterns. The Axon Saga framework is a Spring Boot-based lightweight saga pattern framework. [1]
How to decide which saga pattern should you use?
System complexity: The orchestration pattern is appropriate for systems with complicated business logic, where the control flow must be controlled centrally to maintain consistency and compliance with business requirements. The choreography pattern, on the other hand, is better suited for systems with basic business logic, where services can work independently and interact via event-based communication. [3]
Coordination requirements: The orchestration pattern is beneficial when tight coordination and interaction between services is required, as the orchestrator may handle communication and guarantee that each service completes its duty before moving on to the next. The choreography design, on the other hand, is better suited for loosely connected systems in which each service can work independently and communicate with other services as needed. [3]
Fault tolerance and scalability: Because the central orchestrator can handle errors and retries and improve system flow, the orchestration pattern can be more fault-tolerant and scalable. Choreography patterns, on the other hand, can be more durable and flexible to changes because each service can react to events and update its behavior without relying on a central component. [3]
Centralization vs. decentralization trade-offs: The orchestration pattern centralizes control and decision-making, which simplifies system development and management but introduces a single point of failure and a possible bottleneck. The choreography pattern, on the other hand, distributes power and decision-making, which can boost service autonomy and flexibility while also making the system more complex and difficult to operate. [3]
Implementing Choreography-based Saga Pattern in Spring Boot
Event Sourcing
Every change in an application’s state is recorded as an event. This event is saved in the database/event store (for tracking purposes) and is also broadcast on the event bus for consumption by other parties. [4]
A command to make a new order is received by the “order-service”. This request is executed and raised as an event when an order is created. OrderCreated event (used past tense because it has already occurred) simply informs “order-service” that a new order request has been received and is being held in the PENDING/CREATED status and it has not yet been fulfilled. [4]
The payment/inventory service may now be interested in listening to those occurrences and reserving/rejecting payment/inventory. Even these might be considered an event. Payment has been reserved/rejected for the event. Payment reserved/rejected event and Order-service may listen to these events and fulfill/cancel the initial purchase request. [4]
Project’s source code:
Implementing Orchestration-based Saga Pattern in Spring Boot
The orchestrator is a distinct service that will coordinate all transactions between all Microservices. If everything is in order, the “order-request” is marked as complete; otherwise, it is marked as canceled. To make this stateless, communication between the orchestrator and other services would be via basic HTTP in a non-blocking asynchronous manner. For this communication, we can also use Kafka topics. For that, we have to use the scatter/gather pattern which is more of a stateful style.[5]
Project’s source code:
Implementing Orchestration-based Saga Pattern in Spring Boot with Axon Framework
Axon Framework, Axon Server, SpringBoot, and H2 Database will be used in this implementation. [6]
The project involves four services: order service, payment service, shipping service, and common service.[6]
Order Service exposes APIs that assist in the creation of an Order in the system. The service also manages the Order Aggregate. The Order Service, on the other hand, serves as the home for the actual Order Processing Saga implementation.[6]
Payment Service responds to the Order Processing Saga’s Create Payment Completed Command. When it has completed its task, it publishes an event that advances the Saga.[6]
The shipping Service takes care of creating an Order shipment command issued by the Order Processing Saga. Once it does its job, it also publishes an event that pushes the Saga forward.[6]
Common Service is not a type of service. It serves as the integration glue between the numerous services that compose the Saga. It contains common commands and events that will be utilized by multiple services. [6]
Axon Server is part of the Axon Platform. Axon Framework will be used to manage our Aggregates such as Order, Payment, and Shipment. [6]
Order Aggregate is a critical component of our Saga Pattern implementation. It serves as the foundation for the Order Management Saga. The Axon-specific annotations @Aggregate and @AggregateIdentifier are particularly noteworthy. Axon Framework can manage Order Aggregate instances thanks to these annotations. [6]
Our API endpoints are created in the Order Controller class. For the purposes of our demonstration, we only have one end-point at this time. When a new Order is created in our application, the Create Order Command is invoked. The Order Aggregate is in charge of this command. The Order Event Handler class will handle events from various sources. We will store the details in a local database in data members. [6]
The Order Management Saga is at the heart of the Saga Pattern implementation. In a sense, this is a standard Java class that describes the various handlers for the various Saga phases. The various Saga steps are manageable declaratively. In other words, this makes it exceedingly simple for a developer to understand the Saga’s flow at a glance. [7]
The event will be received and processed by the Payment Aggregate service. ShipmentAggregate is in charge of handling the event and processing the incoming event. [7]
For codes check: [6][7]
References
[1] Baeldung, (10 November 2022), Saga pattern microservices:
[https://www.baeldung.com/cs/saga-pattern-microservices]
[2] Şefik Can Kanber, (12 April 2021), Saga pattern nedir?
[https://sefikcankanber.medium.com/saga-pattern-nedir-e4a447bef361]
[3] Hemesh Thakkar, (2023), Microservices Orchestration vs Choreography: What should you prefer?
[https://www.accionlabs.com/microservices-orchestration-vs-choreography-what-to-prefer]
[4] Vinoth Selvaraj, (2020), Choreography Saga Pattern with Spring Boot:
[https://www.vinsguru.com/choreography-saga-pattern-with-spring-boot/]
[5] Vinoth Selvaraj, (2020), Orchestration Saga Pattern with Spring Boot:
[https://www.vinsguru.com/orchestration-saga-pattern-with-spring-boot/]
[6] Knoldus, (14 November 2022), Implementation of SAGA with AxonFrameWork with SpringBoot Part 3:
[https://blog.knoldus.com/saga-axonframework-springboot-1/]
[7]Knoldus, (18 November 2022), Implementation of SAGA with AxonFrameWork with SpringBoot Part 2:
[https://blog.knoldus.com/blog-knoldus-com-saga-axonframework-springboot-2/]
