Event Sourcing & CQRS · Event Sourcing in Practice
Process Managers and Policies
React to events and coordinate long-running processes.
Policies ("whenever X happens, do Y") react to events by issuing commands — e.g., when OrderPlaced, AuthorizePayment. A process manager (or saga) keeps state across multiple events to coordinate a process with timeouts and compensations. Process managers can themselves be event-sourced. They're the place for side effects (emails, external calls) — never projections.
Who does what
| Component | Responsibility | Side effects? |
|---|---|---|
| Aggregate | Enforce invariants, emit events | No |
| Projection | Build read models | No |
| Policy | Event → command (stateless) | Via commands |
| Process manager | Coordinate multi-step processes (stateful) | Yes, via commands/activities |
OrderFulfillment process manager (state: awaiting_payment → awaiting_stock → shipping → done)
on OrderPlaced → send AuthorizePayment; set timeout 15 min
on PaymentAuthorized → send ReserveStock
on StockReserved → send CreateShipment
on StockUnavailable → send VoidPayment, send CancelOrder
on timeout(payment) → send CancelOrder(reason='payment timeout')
Common pitfalls
- Side effects in projections.
- Process managers without timeouts.
- Policies that aren't idempotent (events redelivered).
Key points
- Policies: stateless reactions
- Process managers: stateful coordination
- Side effects live here, idempotently
Further reading: EIP: Process Manager
Practice questions
What's the difference between a policy and a process manager?
Answer
A policy statelessly maps one event to a command; a process manager tracks state across several events and timeouts to coordinate a multi-step process.
Why must policies be idempotent?
Answer
Events are delivered at least once; a redelivered event must not issue duplicate commands with duplicate effects.
Open in the app to mark lessons complete, take notes and track your progress.