Start with a requirement
Select what your system must do. Patterns are ranked by how directly they deliver the selected requirements: a primary fit scores 2, a secondary fit 1.
Requirement reference
Every requirement, the capabilities it needs and the patterns that provide them.
Long-running workflows
“A workflow runs for hours or days and must survive restarts and deploys.”
Needs
- Persistent execution state
- Resume after failure
- PrimaryDurable ExecutionRecords every step so the workflow resumes exactly where it stopped, and waits cost nothing while suspended.
- Also considerCheckpointingLighter option: snapshot state at chosen points when a full durable engine is more than you need.
- Also considerState MachinePersist the current state so a long lifecycle can be picked up by any process.
Parallel work
“Several workers must execute in parallel and rejoin.”
Needs
- Parallel execution
- Result aggregation
- PrimaryFan-out / Fan-inSplits work into independent parts, runs them concurrently and joins results at an explicit point.
- Also considerDAGUse when the parallel branches are part of a fixed dependency graph in a scheduled pipeline.
Human approval
“A human must approve before execution continues.”
Needs
- Wait for external input
- Persistent execution state
- PrimaryHuman-in-the-loopPauses at a defined gate and resumes on the approve, reject or edit path.
- Also considerDurable ExecutionKeeps the paused workflow safe for days without holding a worker.
- Also considerCheckpointingAgent frameworks implement approval interrupts by checkpointing and resuming state.
Failure recovery
“I need retries that survive process restarts.”
Needs
- Automatic retries
- Resume after failure
- PrimaryDurable ExecutionRetry state lives in the engine, not the process, so retries continue after a crash.
- PrimaryRetry & FallbackDefines the retry policy and what to do when retries are exhausted.
- Also considerCheckpointingRestarts from the last snapshot instead of the beginning after a crash.
Multi-agent coordination
“One controller delegates work to specialist agents.”
Needs
- Central delegation
- Control transfer
- Runtime branching
- PrimarySupervisorA central coordinator delegates, reviews and owns the final result.
- Also considerHandoffUse when specialists should take over the task directly instead of reporting back.
- Also considerRouterUse when a single dispatch decision is enough and no ongoing coordination is needed.
Distributed transactions
“Multiple services participate in one business transaction.”
Needs
- Compensating actions
- Decoupled coordination
- Persistent execution state
- PrimarySaga / CompensationPairs every local transaction with a compensation so partial failures are undone.
- Also considerEvent ChoreographyRuns the saga through events when services should stay decoupled from a coordinator.
- Also considerDurable ExecutionMakes an orchestrated saga crash-safe: owed compensations are never forgotten.
Persistent execution state
“Execution state must persist between steps and across failures.”
Needs
- Persistent execution state
- PrimaryCheckpointingSaves state snapshots you can restore, inspect or branch from.
- PrimaryDurable ExecutionPersists every step automatically as an event history.
- Also considerState MachineReduces persisted state to one explicit, valid state per instance.
Dynamic routing
“The next step depends on runtime state.”
Needs
- Runtime branching
- Explicit states and transitions
- PrimaryRouterClassifies each input or state and dispatches it to one path.
- PrimaryState MachineMakes the allowed next steps explicit for every state and event.
- Also considerHandoffLets the active agent pass control on when the task changes domain.