Disclosure: This article may contain affiliate links. When you purchase, we may earn a commission.

SAGA Microservice Design Pattern In Java

Hello guys, if you want to learn about SAGA Microservice design pattern then you have come to the right place. SAGA is one of the 10 essential Microservice Design Patterns I have shared earlier and it solve a critical problem related to distributed transaction. But, before we get to the different examples that will teach you all about SAGA microservice design patterns in Java, let me tell you a bit more about what it really is. A microservice-based application is basically a distributed system. The overall system consists of multiple minor services, which provide the overall application functionality. This architectural style offers numerous benefits as well as several limitations. SAGA Pattern is also one of the popular Microservice interview question and if you are going for interview, it make sense to learn and understand this design pattern in depth. 


One of the major problems in a microservice architecture is how to handle a transaction that spans multiple services. In a Microservice architecture, we can choose the technology stack per service. For example, we can decide to use a relational database for service A and a NoSQL database for service B.

This model allows you to service to manage domain data independently on a data store that best suits its data types. It also lets the service scale its data stores on demand.

Sometimes, a transaction can span across multiple services. In such cases, you have to ensure data consistency across the service database. 

We’ll take an example of an e-commerce application that processes online orders and is implemented with microservice architecture for demonstrating the use of distributed transactions. There is a particular microservice to create the orders, one that can process the payment, another that can update the inventory, and the last one that delivers the order.

SAGA Microservice Design Pattern In Java


All four microservices must complete the individual local transactions. If any of the microservices fail to complete the local transactions, all the completed preceding transactions should also roll back to ensure data integrity.

In the case of distributed transactions, the first challenge is maintaining ACID.  You have to ensure the correctness of a transaction: it must be Atomic, Consistent, Isolated, and Durable (ACID). The atomicity will ensure that all of the steps of a transaction should be complete. Consistency will take data from one valid state to another valid state.

Isolation can guarantee that concurrent transactions should produce the same result that sequentially transactions could have produced. Finally, durability means that committed transactions will remain committed irrespective of any type of system failure. In a distributed transaction scenario, as the transaction spans several services, ensuring ACID always remains key.

Another challenge is to manage the transaction isolation level. It can be used for specifying the amount of data that is visible in a transaction when the other services access the same data simultaneously.

The Two-Phase Commit protocol, or 2PC, is actually a widely used pattern that can be used to implement distributed transactions. You can use this pattern in a microservice architecture for implementing distributed transactions.

In a two-phase commit protocol, there will be a coordinator component that will be responsible for controlling the transaction. It will also contain the logic to manage the transaction. The other component is basically the participating nodes (e.g., the Microservices) that run their local transactions.

Some of the drawbacks of 2 phase commit are given below:

1. The responsibility of the transaction will be on the coordinator node. This means that it can become the single point of failure. All other services will need to wait until the slowest service finishes its confirmation. The overall performance of the transaction is bound by the slowest service.

2. The two-phase commit protocol is actually very slow by design because of the chattiness and dependency on the coordinator. Therefore, it can lead to scalability and performance issues in a microservice-based architecture involving multiple services.

3. The Two-phase commit protocol is not supported in NoSQL databases. So, in a microservice architecture where one or more services use NoSQL databases, you can’t apply a two-phase commit.

The Saga architecture pattern will give you transaction management using a sequence of local transactions.

You can think of a  local transaction as the unit of work performed by a Saga participant. Each and every operation that is part of the Saga can be rolled back by a compensating transaction. Also, the Saga pattern will guarantee that either all operations complete successfully or that the corresponding compensation transactions are run to undo the work previously completed.

In the Saga pattern, a compensating transaction has to be idempotent as well as retryable. These two principles will ensure that you can manage transactions without any manual intervention.

The Saga Execution Coordinator is basically the central component for implementing a Saga flow. It is made up of a Saga log that captures the sequence of events of a distributed transaction. In case of any failure, the SEC component inspects the Saga log to identify the impacted components and the sequence in which the compensating transactions should run.



SAGA Microservice Design Pattern Interview Questions and Answers

Now, let's check out common questions about Microservices and SAGA Pattern in particular which are also popular on Java interviews:

1. What do you mean by SAGA microservice design patterns in Java?

This model allows you to service to manage domain data independently on a data store that best suits its data types. It also lets the service scale its data stores on demand. Sometimes, a transaction can span across multiple services. In such cases, you have to ensure data consistency across the service database.

2. What is a microservice?

A microservice-based application is basically a distributed system. The overall system consists of multiple minor services, which provide the overall application functionality. This architectural style offers numerous benefits as well as several limitations. One of the major problems in a microservice architecture is how to handle a transaction that spans multiple services.


SAGA Microservice Design Pattern Explained


3. What do you mean by ACID?

In the case of distributed transactions, the first challenge is maintaining ACID.  You have to ensure the correctness of a transaction: it must be Atomic, Consistent, Isolated, and Durable (ACID). The atomicity will ensure that all of the steps of a transaction should be complete. Consistency will take data from one valid state to another valid state. 

Isolation can guarantee that concurrent transactions should produce the same result that sequentially transactions could have produced. Finally, durability means that committed transactions will remain committed irrespective of any type of system failure. In a distributed transaction scenario, as the transaction spans several services, ensuring ACID always remains key.

Conclusion

That's all about what is SAGA Design Pattern, what problem it solve in Microservice architecture and how and when to use it. If you liked this article on SAGA microservice design patterns in Java, feel free to share it with your friends and family. I have no doubt that the courses in this article will transform you from a complete beginner to a Java expert within a matter of weeks or months. 

You can also drop a comment if you have any doubts about microservice design patterns, and we will get back to you as soon as possible. 

No comments:

Post a Comment

Feel free to comment, ask questions if you have any doubt.