Choreography based Saga Pattern using dotnet 6
This article showcases how to implement Choreography based Saga pattern for microservices using sample dotnet code. You can find the sample code used in this article here.
Microservices are the foundation of distributed systems. One of the pain point of developers and architects is to process a request which span across multiple services. In this type of distributed system each service might have it’s own database and to keep the data consistent across the request, one solution is to use Saga Pattern. There are two ways to implement Saga Pattern: Choreography and Orchestration. I have explained about Saga and Orchestration pattern in this article.
This article is about Choreography pattern, So let’s talk about it. Both of the patterns have some pros and cons. Based on the use case one should decide on which one to use. Orchestration has some good benefits and one of the most important is having the coordinator(or orchestrator) which is at the heart of the system and which hides all the complexities and provides a very simple way to design complex workflows. But that also brings a single point of failure in the distributed system. The way to avoid that is to use Choreography design pattern.
In Choreography there is no central coordinator/orchestrator, Instead it uses domain events. Here all the communication between different microservices happens in asynchronous way using messages/events. I hope most of you will be very much familiar with events and how to use them in distributed system architecture.
For demo purpose, I have used the below diagram and have created a sample app based on the same. You can find the sample code here.
Here the status of orders is dependent on customer service. So if the credit is reserved or limit exceeded, based on that order service updates the status and hence data is in proper and consistent state. I have chosen this sample app because for demonstration it is simple to create. If I would have used the example which I have used in Orchestrator demo(shown in below diagram), the solution will become a bit complex to implement and to understand.
If I have to create an application for the above diagram, I have to create a minimum of six events’ queue/channel, two between each of the microservice. You can think of the scenario where we have many microservices and how one is going to keep track of all these events.
Demo Application
For Demo purpose I have created two microservices: Order and Customer and for propagating domain events, I have used RabbitMQ. It’s a very simple application where Order microservice on getting an order as a Post request, send a message to ‘orderEventsQueue’. Customer microservice listens to this queue and process the request(mimicking this by random numbers) and accordingly push the message to ‘customerEventsQueue’. Order microservice listens to this queue and updates the status based on the message received.
I have used the below mentioned ‘docker-compose.yml’ to run these services on Docker Desktop.
You can use ‘docker compose up -d’ to run the application in Docker Desktop. You will get the output like below.
There is no very rigid rule that you need to use only choreography or only orchestrator. It all depends on your use case. If needed you can take best of both and combine it together.
This was a sample use case showing how to implement choreography based saga pattern for microservices. Hope you can find this article useful. You cane read my article on orchestration based Saga Pattern here.
For further reading on Saga pattern you can check out https://microservices.io/patterns/data/saga.html and https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga .
Please do checkout other articles by me and share your feedback(s) if any. Thank you and Happy Coding :)
