# Process Manager vs Saga: What's the Difference?

> A saga coordinates local transactions and recovery across services. A process manager tracks workflow state and decides the next step. They often work together: the process manager orchestrates the saga and its compensations.

Published: 2026-09-22. Author: Milan Jovanović.

Canonical: https://milanjovanovic.tech/blog/process-manager-vs-saga-pattern

A **saga** coordinates a business transaction through local transactions and recovery actions across services.
A **process manager** keeps workflow state and decides which command to send next.
An orchestrated saga commonly uses a process manager, while a choreographed saga distributes coordination across participants.
The patterns describe different responsibilities and can coexist.

## What Does a Saga Coordinate?

The [**saga pattern**](https://learn.microsoft.com/en-us/azure/architecture/patterns/saga) coordinates local transactions across independently managed data stores.
Each participant commits locally; the workflow needs an explicit recovery policy when a later step cannot complete.

A saga is:

- A sequence of **local transactions**, each committed independently in one service.
- A matching set of **compensating transactions** that semantically undo completed steps.
- On a permanent failure, compensate completed steps where the business allows it.
  Transient failures may be retried; compensation order and irreversible steps require explicit design.

Order fulfillment as a saga:

- Reserve stock (compensation: release stock)
- Capture payment (compensation: refund payment)
- Create shipment (compensation: cancel shipment)

If shipment creation fails, the saga refunds the payment and releases the stock.
The system doesn't end up where it started; it ends up in a **new consistent state that acknowledges the attempt**.
A compensation is not a rollback.
The payment really was captured, and the refund is a second, real transaction, visible on the customer's statement.

A saga also needs a success path and retry behavior.
Its coordination can be centralized or distributed; compensation alone does not choose that architecture.

## Process Manager: A Coordination Pattern

The [**Process Manager pattern**](https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html) maintains process state and chooses the next step based on intermediate results.

A process manager is:

- **Stateful**: it persists where each workflow instance stands.
- **Event-consuming and command-producing**: events flow in ("payment captured"), decisions flow out ("create shipment").
- **The single place where the flow is written down**: branching, timeouts, retries, escalation.

The mechanical shape is a persisted state machine:

```csharp
public class OrderFulfillmentState
{
    public Guid OrderId { get; set; }
    public string CurrentState { get; set; } = "AwaitingStockReservation";
    public bool StockReserved { get; set; }
    public bool PaymentCaptured { get; set; }
    public DateTime StartedAtUtc { get; set; }
}
```

![A process manager consumes events, holds central persisted state you can query and inspect, and produces the next command, keeping the whole flow written down in one place](https://milanjovanovic.tech/blogs/articles/process-manager-vs-saga-pattern/process-manager.png)

When `PaymentCaptured` arrives, the process manager loads the order workflow, checks its state, and decides whether to issue `CreateShipment`.
It must commit the state change and outgoing command together through an outbox, then let a dispatcher deliver the command.
The participants (inventory, payments, shipping) know nothing about the flow; they execute commands and report facts.

Notice what's missing from this definition: compensation.
A process manager can drive an approval workflow or document pipeline without business compensation, though it still needs technical failure handling.
**Coordination and failure-handling are orthogonal concerns**, and the two patterns each own one of them.

## Why Everyone Conflates Them

Because in practice, one component usually does both jobs.

An orchestrated saga needs something to run the compensations in order, and that something is a process manager.
A persisted state machine can implement the process manager role.
When it also coordinates local transactions and their compensations, it implements an orchestrated saga.
The concrete [**Wolverine saga example**](https://milanjovanovic.tech/blog/implementing-the-saga-pattern-with-wolverine) shows how those responsibilities fit together.

So the industry shorthand became "saga" for the whole assembly.
The [**orchestrated saga with MassTransit**](https://milanjovanovic.tech/blog/implementing-the-saga-pattern-with-masstransit) is really a process manager executing a saga's compensation strategy.
Keep two decisions explicit:

- **How do I coordinate?** Central decider (process manager / orchestration) vs. distributed reactions (choreography).
- **How do I handle partial failure?** Retry transient failures, compensate when business rules permit, or escalate for manual recovery.

Coordination style does not eliminate the need to choose recovery behavior.
A choreographed saga has compensation without a central decider.
A process manager without compensation is just workflow orchestration.
The trade-off between the coordination styles is its own topic, which I covered in [**orchestration vs choreography**](https://milanjovanovic.tech/blog/orchestration-vs-choreography).

## How Do the Patterns Compare?

| Concern | Saga | Process Manager |
| --- | --- | --- |
| Purpose | Coordinate a business transaction across local commits | Track progress and choose workflow steps |
| Coordination | Orchestration or choreography | Central workflow decisions |
| Recovery | Retries and business compensation where possible | Defined by the workflow; compensation is optional |
| State | Held by participants and optionally an orchestrator | Explicit state for each workflow instance |
| Overlap | An orchestrated saga can use a process manager | Can orchestrate a saga or a workflow without compensation |

## Where Does Workflow State Live?

**In a choreographed saga, there is no required central coordinator state.**
Inventory listens for `OrderPlaced`, payments listens for `StockReserved`, shipping listens for `PaymentCaptured`.
Each service holds its own piece; the overall progress of order 4712 is implicit in which events have fired.

![In a choreographed saga each service reacts to the previous service](https://milanjovanovic.tech/blogs/articles/process-manager-vs-saga-pattern/choreographed-saga.png)

If shipment creation fails, operations needs to answer **"where is this order stuck?"**

- With a process manager, persisted state can expose the current step, last transition, and deadline.
  Scheduled timeouts and validated recovery commands make intervention explicit.
- With choreography, participants retain their local state.
  An observer can build a correlated progress view without controlling the workflow, but that view and its failure alerts must be designed.

Choreography removes a central coordinator, while participants remain coupled through event contracts and business ordering.
Short linear workflows can be easier to express this way.
Branching and compensations increase the effort needed to understand the process across handlers.

A useful starting point:

- **Two or three steps, linear, low failure stakes**: choreograph, keep it simple.
- **Branching, timeouts, human steps, money, or anything ops must be able to inspect and unstick**: process manager, with compensations defined next to the flow they undo.

The same coordination choice applies across modules.
A modular monolith can use in-process or durable messaging, and I walked through that variant in [**the saga pattern in a modular monolith**](https://milanjovanovic.tech/blog/saga-pattern-modular-monolith).

## Getting the Plumbing Right (Both Patterns)

For message-driven implementations, handle these failure cases explicitly:

- **Atomic state-plus-messages.** A process manager that saves state but fails to send the command (or vice versa) corrupts the workflow. Persist state and outgoing messages in one transaction with the [**outbox pattern**](https://milanjovanovic.tech/blog/outbox-pattern-dual-write-problem).
  Framework support still needs the correct persistence and outbox configuration; an in-memory outbox does not make state and outgoing messages durable together.
- **Idempotent participants.** Retries mean every command can arrive twice. Reserving stock twice for one order must be a no-op, which is the [**idempotent consumer**](https://milanjovanovic.tech/blog/the-idempotent-consumer-pattern-in-dotnet-and-why-you-need-it) discipline applied to workflow steps.

- **Idempotent coordination.** Deduplicate incoming message IDs and reject invalid transitions. Save the inbox record, changed workflow state, and outgoing messages in one database transaction.
- **Concurrent delivery.** Use a concurrency token or per-instance locking. After a conflict, reload and reevaluate the event before retrying; do not blindly resend the previously chosen command.
- **Ambiguous outcomes.** Reuse a stable operation ID at participants. A timeout after payment capture does not prove the capture failed, and compensation must identify the original operation.

For example, a duplicate `PaymentCaptured` received after entering `AwaitingShipment` must not enqueue a second shipment.
A different payment ID for that same step is a discrepancy to investigate, not a duplicate to ignore.
Persist deadlines, retry attempts, and a recovery state for compensation that cannot complete automatically.

And design compensations as first-class business operations, not technical afterthoughts.
"Refund payment" has rules (partial refunds? fees? time limits?) that the domain experts, not the messaging framework, must define.
Some steps aren't compensatable at all (an email is sent; a report went to the regulator), which is why real workflows order steps so that the hardest-to-undo actions come last, a pivot point worth designing consciously.

## Summary

- **Saga** coordinates local transactions and recovery across a business operation.
- **Process manager** keeps explicit workflow state and decides the next step.
- **Orchestrated sagas** commonly use a process manager; choreography distributes decisions across participants.
- **Reliability** requires durable state, configured inbox/outbox behavior, concurrency control, and idempotent operations.
- **Compensation** is a business action that can itself fail, so give it retries, visibility, and a recovery path.

Choose the coordination style based on branching, failure behavior, and what operations needs to inspect.
A small workflow can use choreography; a workflow with deadlines or manual intervention often benefits from explicit central state.

Thanks for reading.

And stay awesome!

---

## Frequently asked questions

### What is the difference between a saga and a process manager?

A saga is a sequence of local transactions with compensating actions, focused on undoing partial work when a step fails. A process manager is a stateful component that receives events, decides what should happen next, and sends commands. An orchestrated saga commonly uses a process manager, so the patterns overlap rather than being mutually exclusive.

### Is a MassTransit saga actually a process manager?

Mostly yes. A MassTransit state machine holds central state, reacts to events, and dispatches commands, which is the process manager pattern. It is also the natural place to implement compensation, so in practice it plays both roles.

### Where does workflow state live in a choreographed saga?

Nowhere central. Each service knows only which events it reacts to, so the overall progress of the workflow exists implicitly across all participants. Answering "where is order 4712 stuck" requires correlating events from every service involved.

### When should I use a process manager instead of choreography?

When branching logic, timeouts, or operational visibility justify explicit workflow state. Central state makes the process explicit, debuggable, and resumable.

### What is a compensating transaction?

An explicit business action that semantically undoes a completed local transaction, like refunding a captured payment or releasing reserved stock. It is not a rollback; the original transaction committed, and the compensation is a new transaction that reverses its effect.