In this video, we are going to see two types of the implementation.
These are the choreography and the orchestration.
So let me explain.
It's choreography.
Way to set up a then basically choreography provides the coordinate saga with applying public subscribe
principles with choreography.
Each microservice to run its own local transaction and publish event to message broker system and the
trigger to local transactions in other microservices.
This way is good for simple workflows if they don't require too much microservice transaction steps.
But if such a workflow steps increase, then it can be become confusing and hard to manage transactions
between certain microservices because there will be lots of events and it is hard to manage those events
into the transactions.
Also, choreography way decoupled direct dependency of microservices when managing transactions.
So another way of the implementation saga is the orchestration.
Orchestration provides to coordinate signals with a centralized controller microservices.
This centralized controller microservice orchestrate the workflow and invoke to execute local microservice
transactions in sequentially.
So the orchestrator microservice executes the transaction and manage them in a centralized way.
And if one of the step is failed, then executes rollback steps with compensating transaction.
So orchestrating way is good for the complex workflows which include lots of steps.
But this makes a single point of failure with centralized control microservices a need to implementation
of complex steps.
So if you look at the image, the image shows a failed transaction with a single button.
The update inventory operation has failed in the inventory microservices, so when it failed to one
step, the server invokes a set of compensating transactions to roll back the inventory operations,
cancel the payment and the order, and return the data for each microservice back to a consistent state.
So we should careful about when using a pattern in distributed microservice architectures.
If our use case required data consistency across several microservices and required roll back one one
step is failed.
Then we should use saga pattern.