What is the difference between a saga, a process manager and a document-based approach?

Question

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:

• What is a saga in contrast to a process manager?
• There is also the document-based approach, as mentioned in CQRS sagas - did I understand them right? … as I understand it, a document is just a "piece of paper" where you take notes and hand it around. How does that fit into the concept of commands and events?

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? …?

Revers

In 1987, some guy published a paper, attaching his concept to the word "Saga". This short-sightedness forever took away anyone's capability to use the 4-character (therefore highly desirable) word as a moniker for any other similar concept. So now we all have to type longer words like ProcessManager or Workflow as we are programming. This is readily enforced by some people on the internet. – Rohde

Do you have any sources for this? – Revers

While being mainly satirical, yes I do have a source. amundsen.com/downloads/sagas.pdf – Rohde

I prefer the term 'Policy' it is short, and is often congruent with business terms... not technical jargon. – Randolf

Answer 1

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:

• Sagas and Workflows - same thing with different names or not (Arnon Rotem-gal-oz)
• Clarifying the Saga pattern (Kelly Sommers)
• Sagas (Clemens Vasters)

Pechora

These two patterns plus the retry pattern are often combined into the Scheduler Agent Supervisor pattern. More explanation: medium.com/@juan.castaneda.dominguez/… – Circumlocution

I keep reading this difference and I can say for sure I am still confused because to me they reason out the same. So let me is ask, is a saga= movie and process manager= actor? – Everick

None of the "Other Resources" links work today (March 2022). They all 404. – Sardinia

Answer 2

Take a look at CQRS Journey project on MSDN:

http://msdn.microsoft.com/en-us/library/jj591569.aspx

Clarifying the terminology

The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this:

There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact.

Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition.

The term saga, in relation to distributed systems, was originally defined in the paper "Sagas" by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction.

Eckart

Thanks for replying that fast. I already knew this explanation, but at least for me it does not explain what sagas are, only what their intent is - and to be true, I can not see the difference to the intent of a process manager. What's the difference in the concept? Is it simply two sides of the same coin? Can you exchange one with the other? Or are there scenarios where you need exactly one or the other? – Revers

I understand that Process Manager is a new term for Saga that was introduced to limit confusion with a different meaning of the term Saga in distributed transactions world. So Process manager is Saga in CQRS. – Eckart

Does saga have state? – Blythebm

Yes, it does. It needs to track what actions took place and what their result was, etc. – Eckart

Answer 3

Saga has no state while Process Manager has.

Another difference - Process Manager is a state machine, Saga is not.

Saga does not have

• state machine state
• data state (some persisted data)

.. and Process Manager has

• state machine state
• data state (some persisted data)

Read more in my blog: http://blog.devarchive.net/2015/11/saga-vs-process-manager.html

Langham

always include conslusions from links, even if it's your own blog ;) – Forman

I'm sure that a saga can have state? How can it be long running and crash tolerant, if not? – Crashland

Thomas Eyde, - Saga state is encapsulated in the messages themselves, there is no central storage as it is in Process Manager case – Langham

Answer 4

Saga and Process Manager are two integration patterns. They are very alike, but not in total.

• Saga is a pattern that helps you to implement each business transaction that spans multiple services as a saga. In fact, you will create a sequence of local transactions where each local transactions updates the database and publishes a message or an event to trigger the next local transaction in the saga. There are two possible ways to implement a saga: Orchestration (an orchestrator tells the participants what local transactions to execute) and Choreography (each local transaction publishes domain events that trigger local transactions in other services). Is very common that using Saga will determine the usage of CQRS and EventSourcing.
• Process Manager is a processing unit that it's existing in order to mantain the state of the sequence and determine the next processing step based on intermediate results. It's a routing pattern. It's more like an Orchestrator Saga.

Lurleen

Answer 5

Both Process manager and saga route a message through multiple processing steps when the required steps may not be known at design time and may not be sequential.

Process manager pattern is a durable event scheduler that encapsulates process specific logic and maintain a central point of control deciding what to execute next once a process is completed. Process managers maintain state so for example say a payment was taken from a customer, the fact an order must now be sent to them is persisted in the process manager.

Saga manager pattern. Encapsulates process logic deciding what to execute next once a process is completed. A saga holds no state so decideds what to do next based entirely on the content of the incoming message or event. So in the case when a payment is taken by a process, that process also creates a new message indicating an order must now be sent, including what needs to be sent and to whom. The message also contains additional payment information so if something were to go wrong sending the order the payment gets refunded.

Ascanius