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.
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
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?
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
Other Java Microservices articles and tutorials you may like:
- Top 5 Courses to learn Microservice with Spring Boot
- What is Event Sourcing Pattern in Microservices?
- 15 Microservice Interview Question and Answers
- 10 Advanced Spring Boot Courses for Java Programmers
- What is CQRS Pattern in Microservices Architecture
- 5 Free Spring Framework Courses for Java Developers
- How to create Microservice with Java and Spring
- 10 Free Courses to learn Spring for Beginners
- 5 Best Courses to learn Spring MVC for Beginners
- 5 Online Courses to learn Core Java for Free
- 5 Books to learn Microservice in Java
- 10 courses for Programming/Coding Job Interviews
- 10 Free Spring Boot Tutorials and Courses for Java Devs
- 5 Essential Frameworks Every Java developer should learn
- 5 Essential Skills to Crack Coding Interviews
- 10 Best Courses to learn Spring in-depth
- Top 5 Java design patterns courses for experienced Java devs
Thanks for reading this article so far. If you like this SAGA Microservice design pattern and when and how to use it then please share them with your friends and colleagues. If you have any questions, feedback, or other fee courses to add to this list, please feel free to suggest.
Please add some real time code example for SAGA pattern
ReplyDeleteComplex to understand
ReplyDelete