Process Manager
A Process Manager centrally maintains the state of a multi-step message flow and decides each next step, orchestrating complex, branching, or long-running workflows. It offers clear control and a home for compensation logic at the cost of being a stateful, potentially bottlenecked coordinator.
A Process Manager is a central, stateful component that orchestrates a sequence of steps in a message flow. It receives messages, tracks where each process instance stands, decides the next action based on that state, and dispatches the corresponding command. Unlike a routing slip, where the route travels with the message, the process manager holds the logic and state centrally.
The problem it solves is coordinating complex, long-running, branching workflows. When a business process spans many services and steps, may branch on results, run steps in parallel, wait for events, and require error handling, neither static pipelines nor self-routing messages are enough. A process manager provides explicit, stateful control.
How It Works
For each process instance the manager keeps state, keyed by a correlation identifier. It starts when a triggering message arrives, creating an instance. As each step's reply or event comes back, the manager updates the instance state and uses its workflow definition to decide what to do next — send the next command, branch, wait, run steps concurrently, or finish. It often persists state so instances survive restarts and can wait for events that arrive much later.
This is orchestration: one coordinator directing participants, in contrast to choreography where services react to events without a central driver.
trigger --> [Process Manager: instance state] --> step1
step1 reply --> update state --> branch --> step2a / step2b --> ... --> done
When to Use It
Use it for multi-step business processes with branching, parallelism, timeouts, or waiting; for distributed transactions needing coordinated compensation (the orchestration-based Saga); and when you need a single place to see and control a workflow's status. Workflow engines like Camunda, Temporal, and AWS Step Functions implement this pattern.
Avoid it for simple linear flows, where a routing slip or plain choreography is lighter, and beware of centralizing too much logic into one brittle coordinator.
Trade-offs
A process manager gives clear, centralized, observable control over complex flows and a natural home for compensation and timeout logic. The costs are statefulness — persistence, scaling, and recovery of in-flight instances — and the risk that the coordinator becomes a complex bottleneck and a single point of failure. Centralized orchestration can also couple the manager to many services.
Related Patterns
It implements the orchestration style of the Saga pattern for distributed transactions. It contrasts with the Routing Slip's decentralized routing. It uses Correlation Identifiers to track instances and may use an Aggregator to gather parallel results.
Example
An order-fulfillment workflow in Temporal starts an instance per order, calls payment, then in parallel reserves inventory and books shipping, waits for both, and on any failure runs compensating steps to refund and release stock. The process manager holds the state and drives each transition.