What are sagas in microservices ?
A?database-per-microservice?model provides many benefits for microservices architectures. Encapsulating domain data lets each service use its best data store type and schema, scale its own data store as necessary, and be insulated from other services' failures. However, ensuring data consistency across service-specific databases poses challenges. Two answers for this chanllenge : two phase commit , Sagas
The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios through:
- A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step.
- It also provides transaction management using a sequence of?local transactions which is the atomic work effort performed by a saga participant that updates the database and publishes a message or event to trigger the next local transaction in the saga.
- If a local transaction fails, the saga executes a series of?compensating transactions?that undo the changes that were made by the preceding local transactions.
What is Spring state machine ?
State machine?is a?model of computation based on the finite states .Usually there are workflows to go with the states. The transitions between these states are limited by the rules. The Spring framework?has a whole library called Spring State Machine.Please see my previous article
How to Model Sagas as state machine ?
Modelling a saga orchestrator as a state machie is an effective way to manage distributed transactions :
- Use a state machine that consists of a set of states and a set of transitions.Transitions between states that are triggered by events. Each transition can have an action, which for a saga is the invocation of a saga participant. The transitions between states are triggered by the completion of a local transaction performed by a saga participant.The current state and the specific outcome of the local transaction determine the state transition and what action, if any, to perform.
- ?The saga orchestrator is linked to a state machine, which is responsible for managing transaction states through a state manager API. In addition to that, it is also responsible for storing transaction states in a persistent data store to ensure recovery when system faults happen.
- The saga state machine thus has the responsibility to either get the overall business transaction completed or to leave the system in a known state, so that it can determine the order in which to potentially execute the next state of actions, or compensation activities, whether transactions occurring are distributed in nature or, long lived.
What are the best practices for Saga Orchestrator state machine ?
- Orchestrator should only be responsible for managing transactions and states, and there should not be any business logic added here. Business logic should be defined in individual service participants.
- All events and commands to and from the orchestrator should be carrying only transaction data, not reference data.
- Use asynchronous style messaging to communicate between services.
- Implement idempotency and state checks for resiliency, if using message brokers like Kafka.
What are the advantages of this Model ?
- Simpler dependencies — The orchestrator depends on the participants but not vice versa, and so there are no cyclic dependencies.
- Less coupling —?Each service implements an API that is invoked by the orchestrator.
- Separation of concerns —?The saga coordination logic is localized in the saga orchestrator.
- Data Consistency —?Data consistency across multiple microservices
- Developer experience?- Focus Only on business logic
References:
[1] https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga
[2] https://www.youtube.com/watch?v=vx8a0Wrvo64
[3] https://levelup.gitconnected.com/modelling-saga-as-a-state-machine-cec381acc3ef
