Saga VS Process Manager

Diego Martin | 04 May 2020

Saga and Process Manager diagram

This is yet another confusing subject due to the multiple different understandings and explanations about it.

Some people call Saga to Process Managers and viceversa, or they simply call Saga to everything, and it's really confusing trying to understand what somebody means when mentioning either out of context.

They're both integration patterns for distributed architectures and long living transactions but they have different meaning.

Saga

The concept of Saga was first used in a paper in 1987 by Hector Garcia Molina and Kenneth Salem at the Princeton University in the context of database transactions to avoid locking.

It is a failure pattern, something that keeps track of transactions so that it can initialize a compensation action when something fails. It's something to favor compensation over consistency thus avoiding locks.

It generally does not need state as it is a relatively simple reaction mechanism. Think of it as a policy that triggers a compensating action (e.g: a new command to initialize a new transaction) when something bad happens.

Process Manager

On the other hand, a process manager is a workflow pattern implemented as a state machine because, unlike Sagas, it has state. It remembers what has happened and knows exactly which action should be taken in response to each message (e.g: an event) in a deterministic way. It can take into account some business logic such as the time constraint and the order of the events. It can be either a central unit of processing that is responsible for the overall flow, or a distributed one where the next paths are provided with the message.

A process manager is extremely useful for a business as it provides traceability in a deterministic way, and knowing the flow is as important, if not more, as knowing the current state.