In this article I share my confusion and findings about Saga pattern. I’m not an expert in Saga or any other mentioned concepts.
What is Saga pattern?
Short answer — Saga is a failure management pattern. In his paper Hector Garcia-Molina, inventor of the pattern, defines sagas as an approach to handling system failures in long-running transactions. You can watch this talk about using sagas in distributed systems.
The road to sagas
There’s a great article “Clarifying the Saga pattern” which explains very well different patterns which sometimes incorrectly named as Saga.
Quick recap of those patterns:
State machine — a set of defined states, where transition between states is initiated by triggering an action.
Workflow — a sequence of activities, where transition between them occurs when the previous activity is completed. Workflows can include branching to other activities. A workflow can be built on top of a state machine. A process manager is a workflow pattern.
Saga — multiple workflows, each providing compensating actions for every step of the workflow where it can fail. Sagas are not necessarily implemented using workflows.
As you can see Saga is a concept which describes how a system should manage potential errors and it has nothing to do with how it evolves.
Does Saga and CSP have something in common?
Nope. Sagas can be implemented using CSP, but it is not required. CSP is a tool which allows us to orchestrate complex messaging flow. Here’s an example of sagas implemented using Routing slip pattern.
It seems like a lot of different patterns and implementations claim to be a Saga. However it doesn’t make sense to blame those, but it’s also good to know exactly what things are and their origins.
I hope this short explanation will be helpful for everyone who is confused with sagas as much as I was. Make sure to read mentioned articles and watch the talk, they will give more information.