Process Manager
A process manager is a stateful coordinator that drives a multi-step business process: it consumes events, maintains the workflow state, and issues the next commands toward completion.
Definition
The process manager pattern centralizes workflow logic in one component that tracks process state, decides next actions from incoming events, and sends commands to participants. Unlike a saga coordinator that primarily compensates failures, the process manager is the ongoing brain of a long-running workflow — order fulfillment, claims processing, provisioning — persisting its state across restarts.
Context and scope
Implemented with workflow engines (Temporal, Camunda, AWS Step Functions), message-driven orchestrators, or hand-rolled state machines. Enterprise Integration Patterns defines the messaging shape.
Common misconceptions
- The process manager owns the business data — it owns the process state and coordination; business data stays in the participating services
- Orchestrators are a bottleneck by design — they are a single logical coordinator, horizontally scalable via stateless workers over persisted state
- It replaces sagas — sagas are a specific transactional pattern; process managers are the general coordination machinery sagas run on
Anti-patterns
- Embedding business rules inside the process definition instead of in services, recreating a distributed monolith brain
- Keeping process state in memory without persistence and losing in-flight workflows on every deploy
- Letting the process manager call participants synchronously and losing the async resilience the pattern provides
Related concepts
Authoritative source
https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html
What it is
Multi-step workflows need someone to answer what happens next. Distributed choreography hides the answer across services; the process manager holds it explicitly: a state machine reacting to events with commands.
How it works
The manager consumes domain events, evaluates the process state, and emits commands to advance it. State persists externally — database or event log — so workers are stateless and restartable. Timers and escalations are first-class: the manager wakes itself on deadlines. Failure policies branch: compensate, retry, escalate to humans.
When to use it
Long-running processes with human steps, timeouts, and branching: order lifecycles, insurance claims, infrastructure provisioning. Use when the workflow itself is a domain concept worth modeling explicitly.
Pitfalls
Centralized logic ossifies into change-request queues — version process definitions and run old and new side by side during migrations. Correlation ids must be designed up front: one process instance, many events, ambiguous matching equals corrupted state. Testing the full state machine requires exhaustive path coverage, not per-handler tests.