Microservices Architecture Patterns | SAGA Choreography Explained & Project Creation | JavaTechie

hi everyone welcome to java techy in this tutorial we'll discuss what is saga choreography design pattern and how to handle transaction using this saga pattern we'll consider a small use case and we'll try to understand what exactly this saga and how we can implement it okay so let's get started [Music] so this is the small use case which will use to demonstrate more on transaction feature in monolithic as well as microservice application okay so if you can see this use case when an user placed an order order will be fulfilled if the products price is within the user's credit limit otherwise it will not be fulfilled so this is the simple use case so let's try to map this use case with monolithic approach then we'll see how difficult it could be in dealing with transaction in the distributed microservices system okay so if you can see this diagram we have order service and payment service and both the service pointing to the single database so this is very easy to implement in a monolithic application the entire workflow can be considered as a single transaction because they both the application point to the single database right and also it is easy to commit rollback when everything is in a single database let's say for example order service send request to create a order now again payment service will process the payment so we call the process payment okay in case there is some failure while processing the payment then the entire data will be rolled back not a single data will be inserted to nadb that is how the transaction handle in monolithic and the spring framework provided enough feature to handle the transaction in case of monolithic application but microservices does not follow this principle microservices basically follow the pattern called database per service where order service have its own database similarly payment service have its own database so if you observe there is two micro services and they are pointing to two different database if it is a single database then the approach will be same as monolithic right now let's understand how we can handle in this micro services pattern where it already follow database per service pattern how we can handle the transaction so if you can see this diagram order service has its own database which is responsible for managing the order similarly you have payment service has its own database which is responsible for managing the payments at the very first step order service will receive the request from the user then again order service will redirect that request to the payment service to validate whether that user have enough balance or not to check in the payment service now payment service received that request and validate that user balance in db if he found that user have enough balance to purchase that order he'll deduct the amount from the db and send ok response to the order service once order service receive this ok status immediately will complete the order in case order service didn't receive okay status from the payment service then we'll cancel the order so this workflow is straightforward and very simple right but what if in future you want to introduce another service called inventory service who has his own database so in that case to check the product availability in inventory service again order service need to send an another http request to check the product availability in inventory service right which is not a good approach to design the code unnecessarily for a simple requirement we are firing n number of http request so in future again you just want to introduce another service from order service you need to fire http request to that particular service and another problem i can say order service always assume this payment service and inventory service is up and running in case order service and request and payment service is not available that time then it will be impact on your revenue isn't it so in this approach we found two disadvantages one you need to fire n number of http request and second it will impact on your revenue if there is a application down time right so to overcome this issue microservices developer provided a pattern called saga pattern and we can implement this saga pattern with two approach one is choreography approach and another is orchestration approach so in this tutorial we'll be discussing the choreography based approach by using event sourcing so there will be no http request call we just need to go with the event sourcing approach with choreography okay so now let's deep dive into choreography saga pattern and its architecture as you understand there is two service order service and payment service and both have their own independent database okay so once order service will receive the request from user immediately he will produce an event to the kapka topic and the name of topic is order event so immediately once we publish the event to the order event topic payment service will consume that event and again payment service will take that request and validate it in user balance table to check whether that user have enough balance to purchase that order if he found that user have enough balance to purchase that order immediately payment service will publish another event to the topic and the name of the topic is payment event now to this payment event topic again order service will consume that event okay if order service found that response has a payment completed then order service will complete that order otherwise it will cancel the order so if you observe in this choreography pattern there will be no http request call right initially order service published the event to the order event topic and payment service consumed the event from the same topic then once payment service validated the request again he published the event to payment event topic and order service consume the event from the same topic right so this approach looks good now let's try to sync this approach with one example for example let's say in payment service we have two user user id one not one one not two and they are having balance 4000 and 2000 okay so let's say order service just publish an event with user id 101 product id something and price is 3000 he just published the event with this order event topic and immediately payment service will consume that event he can see the entire message and then payment service will take this request and check in user balance database is run having balance 4000 and he's trying to purchase something 3000 it means he has enough balance to purchase that order so payment service will immediately allow him to purchase the order and will deduct the amount now the rest amount is pending for user 101 is 1000 so immediately payment service after update or after deduct the amount he will publish an event to this payment event topic with the payment status success or completed something like that once order service will consume that event with payment starter success or complete will simply complete the order and the user will get the message something like this now for example let's say user id 101 again want to purchase something so again user service or order service send the request user id 1.1 and product id something different and price is 1200 now payment service again will listen to the same topic and he can view this message or he can view this json right so payment service will take this request and we'll go to the user balance table and check that user id 101 having the amount 1000 and he is trying to purchase something beyond the amount it means it exit the limit right so what payment service will do immediately he will publish an event to the payment event topic with status failed now once order service will listen to that payment event topic or once order service consume that event with payment status failed immediately order service will cancel that transaction or immediately order service will cancel that particular order and user will get a response like this okay user id these payment status failed and order status is cancelled so this is how saga choreography pattern works we'll try to implement the same replica of example we'll create two service order service and payment service and we'll use the same scenario okay and i just want to highlight the text tag we are going to use spring webflox apache kapka spring cloud stream java 8 and also we'll use multi-module project so that we can reuse the component or classes okay so these are the text tag i'm going to implement in this saga pattern so if and you're not aware about what is spring webflocks you can check out my reactive programming playlist similarly if you are not aware about apache kafka you can check out my kapka playlist and spring cloud stream video also available and same multi module project tutorial also available in java techy you just search with this keyword if you are not aware about any of the context okay so next what i am going to do i will just create a skeleton of the multi module project will just create payment service order service and common dto class so that we can reuse the dto or event class okay so i'll just create a skeleton of it and in my next tutorial we'll just add the implementation okay so let's move to the intellij id let's quickly create a multi-module project click on file click on new project then click on spring assistant click next next i'll change the group id com.javateki then artifact id i will specify saga choreography pattern and same i just want to specify as my project name then change jdk version to it also i just need to change the package com.javateki dot saga okay so in this project type instead of maven project just change it to maven palm okay so that it will create a multi-module project now click on next so i just need to our dependency lombok we are going to use spring cloud stream so i will just use cloud stream then we just need to add apache kapka okay so you can use spring for apache kapka since we are using webflocks i just need to add web dependency which will be reactive wave also we are going to use database so i will add gpa and i am going to use mysql so i just need to add my sql connector as well okay so let's cross verify if we missed anything number cloud stream yeah now click on next just click on finish this window so it will download the latest dependency so yeah it's in sync now just close it now we just need to create the modules okay just open this you can see there is no src right only we have the palm.xml and in palm.xml we just added a lot of dependencies api with log stream kapka right and mysql that's fine now let's create the multiple modules inside this so i'll just right click here new then i can see the optional module right just click on that and then just click on maven click next so i'll just use the artifact something like order service here i just i just need to write the logic for only order related stop now click on next click on finish similarly i just need to create another module let's say click next i'll name it payment service okay click next finish similarly i'll just create another module where i will just write all the dto class so that while sending and or consuming the event i just i no need to write those dto class repeatedly in order service and payment service i can maintain it in a common folder so i'll just create new module click next let's say command dtos click next click on finish just enable this auto input now if you object we created three separate module common details now if you go inside this you have src pum.xml this is order service you can find src pom.xml payment service and this is the root pump.xml right so since this is the rootpalm.xml and kapka and cloud stream related stop we just need to perform inside order service and payment service what i will do i'll just copy this dependency okay i'll just remove it from the root in root i will just keep the test related dependency and all the actual dependency i will move into the order service and payment service so let me copy this i just need to copy up to this lombok just copy go to the order service palm dot xml i'll just add a section called dependencies inside that i can copy this dependency okay similarly go to the payment service pum.xml and i will just add this tag dependencies then i'll add this dependency now go to the uh what is that root pom.xml and remove this dependency okay so if you observe now in this root palm.xml we have only test related dependency fine just save it now let's close all then what we can do if you go to any of the dependencies let's say order service pom.xml if you observe the parent is our saga choreography pattern this is your the parent and we added all the required dependency okay similarly common details and order service payment service now let's go to the each service order service and payment service we just need to write the main class manually because we are not creating we didn't create this as a springboard project right we just simply create it as a maven project so let's go to the order service go main then i will just create a package here let's say com.javateki dot saga dot order something like that okay now click on ok so i'll just create a class here new java class let's say order service application i just need to annotate here at the red spring boot application then i just need to write main method and i just need to write spring application dot run and give the class name dot class fine similarly i just need to create another package in payment service as well okay go inside the payment service i'll just go to src main then i'll just create a package here payment something like that okay then i just need to create a class main class i will just name it payment service application then i just need to annotate other spring boot application and need to create the main method and spring application dot run give the class name fine so we created this created three modules and we created main class for order service and payment service we are not writing the main class for common details because we just need to write the dto and event classes here okay we are not going to start this common dtos application okay so what i'll do i'll just add a configuration just click on this type maven then i will give it something like saga build working directory will be this main then command line i just want to clean install okay go to the runner i just want to skip the test case while executing the build click on apply okay now just build it it will take couple of minutes to complete the bid it got failed so on project command details okay so it is expecting main class in common details as well okay so what i'll do even though will not run this application but let me write a main class here new package just add it com javadeckysaga.commons click on ok now let me create a main class let's say java class commands dto application i'll simply just add main method because you didn't add any dependency in common retures form so we don't need any spring boot related class here okay save it now let me run the build so it will take few seconds to complete yeah so if you observe the build is completed saga choreography pattern order service payment service and common details okay so this is what we just created multi module project for our saga choreography pattern so in my next tutorial we'll just implement entire code that's all about this particular video guys thanks for watching this video meet you soon with a new concept

Channel: Java Techie

Views: 12,283

Rating: 4.954751 out of 5

Keywords: spring boot saga, microservice saga design pattern, Saga Choreography, saga choreography spring boot, spring webflux saga, javatechie, saga design patern, microservice spring boot saga

Id: aOen1-pQLZg

Length: 18min 18sec (1098 seconds)

Published: Sat Sep 04 2021