Menu
What I understand is that all three concepts are related to long-running transactions.
A process manager is, to my understanding, a finite state machine which simply reacts on events and emits commands. It does not contain any business logic, it just does routing. Its goal is to bring you to a final state, where you know that your transaction has succeeded or failed.
So far, so good.
But now my problems in understand start:
Can anybody please explain the differences, and - what I'd be especially interested in - which of these concepts is good for what, and when you do need what. Are they mutually exclusive? Can you go along all the way with only one of them? Are there scenarios where you need more than one? …?
861
The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step.
The SAGA pattern is a failure management pattern that brings consistency in distributed applications and coordinates transactions between various microservices to maintain consistency. Command and Query Responsibility Segregation or CQRS is a pattern that separates read and update operations for a data store.
There are two approaches to implement the Saga pattern: choreography and orchestration.
There are two ways to achieve sagas: Choreography : each local transaction publishes domain events that trigger local transactions in other services. Orchestration : an orchestrator (object) tells the participants what local transactions to execute.
What is a saga in contrast to a process manager?
The intent of these patterns is different. A process manager is a workflow pattern which can, as you say, be built on top of a state machine. A process manager will retain state between messages, and will contain logic in order to determine which action should be taken in response to a message (for example, transitioning state or sending another message). Some frameworks incorrectly refer to these as sagas.
By contrast, a saga (according to the original definitions) is a pattern intended to help manage failures. It involves multiple workflows across systems, where each will allow some form of compensating action to be taken in a later transaction in the case of a failure elsewhere.
This compensation is the defining characteristic of a saga. Note that the saga itself does't know what the compensating action might be. Sagas are often implemented using the routing slip pattern.
Are they mutually exclusive? Can you go along all the way with only one of them?
They aren't mutually exclusive - it's likely that, for example, a system participating in a saga might use a process manager to actually handle its piece of processing.
Other Resources
Some of these posts may help provide more detail and provide examples:
129
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
