Asynchronous Microservices
Since the HTTP protocol is not suitable for microservices backends because of the synchronous behavior, the microservices need an asynchronous method to communication. As the previous example the distributed transactions as some data added to the database and others not added to other databases. The Saga pattern will solve that problem. It is a non-microservice implementation pattern and can customize as want as long as following the repercussion.
Saga can implement in two different ways as choreographic and orchestration. choreographic means event based, and orchestration means command based. Both can use on different use cases and has own problems.
First take the choreography pattern and consider about a use case. There is a new connection service and when new connection request comes need to validate weather customer has good reputation or has tv connection. When every verification success this inform to finance service can build the bill of the customer. Then if billing is success operation service convey to start the connection. The event broker is Kafka broker and services talk with Kafka topic.
When new connection come to the service publish the message the event to topic and the verification services same time listen to the requests. Both verification success and there is a topic as verification response and response has published too there. New connection service waiting for the response meanwhile listening to verification response topic. Then new connection service identifies the verification has successes then send different event to new connection topic saying verification is success. The finance service listens to the topic and see the success take the payment and send payment success message to verification response topic. New connection gets the payment success response and again publish in the new connection topic as payment is success. The operation service listens to the new connection topic and when see payment is success it initiates new connection. It again publishes as activate success as to verification response topic. So, there is the solution to the problem and no service waiting for the response everything works fine. If the messaging system is down the microservices cannot communicate but if use MSK or any Kafka cluster and there are multiple replicants and start quickly. This system is good to have a monitoring service because if any service is down can add an alert. If a request has published and no one is waiting the monitoring service can send a notification to the services.
Get Hansika Samaraweera’s stories in your inbox
Join Medium for free to get updates from this writer.
The orchestration model has same new connection service and there is separate command model service. When new connection request coms it tells the command service, and it goes to verify the user details as having a tv connection and legitimate user. that process can do parallelly as well. After verify success command go to finance service and say to get the payment. When it done command service go to activation service and tell to active the new connection. The process is governed by command service and the system can go with hybrid solution with an event driver. Then a new request comes to command service, and it publish to the message broker with a target service.
The disadvantage of choreography there are bunch of events and may create a deadlock situation. Its hard to solve a deadlock situation and would have to do integration testing for thousand of events. Having centralized command module is because it doesn’t change anything and decide own to do next.
Reference
[1] Krish Dinesh.” Lets do it right..! Real Async Microservices | SAGA Microservice Pattern | example inside” Available: https://www.youtube.com/watch?v=GfB_z4Y6YD4&list=PLD-mYtebG3X-wOVHINZf_GKknpJs3Oa3O&ab_channel=KrishDinesh [Accessed: July 21,2022].
[2] Krish Dinesh.” Do it RIGHT..!!! Real Async MIcroservices | SAGA Microservices Architecture Patterns” Available: https://www.youtube.com/watch?v=pb0-HvDxGLI&list=PLD-mYtebG3X-wOVHINZf_GKknpJs3Oa3O&index=36&ab_channel=KrishDinesh [Accessed: July 21,2022].
