Reliability · Established
Durable Execution
Also known as: Durable workflows, Workflow-as-code
Durable execution records every step of a workflow in a persistent log so that the workflow survives process crashes, restarts and deploys, and resumes from the last completed step as if nothing happened.
01Problem it solves
Business processes and agent runs often take minutes to weeks and span many remote calls. Held in process memory, any crash, deploy or timeout loses progress, leaves side effects half-done and forces hand-written recovery code.
02Use when / Avoid when
Use when
- The workflow runs longer than a single process can be trusted to stay alive.
- Steps call external systems and a crash must not repeat or skip them.
- You need timers or waits measured in hours or days without holding a worker.
- Retry, timeout and recovery logic is currently scattered across queues, cron jobs and status tables.
Avoid when
- Short, stateless request/response work where a plain retry of the whole call is acceptable.
- Pure data transformation batches that a DAG scheduler already handles well.
- Teams that cannot accept the determinism constraints the engine places on workflow code.
03How it works
- 1StartA workflow is started with an id and input; the engine persists the start event.
- 2RecordEach side-effecting step (activity) is executed by a worker and its result is appended to an event history.
- 3CrashIf the worker dies, the history remains in the engine's store.
- 4ReplayA new worker replays the workflow code against the history; completed steps return their recorded results instead of running again.
- 5ContinueExecution continues from the first step without a recorded result.
04Capabilities
| Capability | What it means |
|---|---|
| Persistent execution state | Progress, variables and position in the workflow are stored outside process memory, so a crash does not lose where execution was. |
| Resume after failure | A stopped or crashed run continues from its last recorded point instead of starting over. |
| Automatic retries | Failed steps are re-attempted according to a declared policy (attempts, backoff, retryable errors) rather than ad hoc code. |
| Wait for external input | Execution pauses until an outside signal arrives (an approval, a callback, a human edit) without holding compute while it waits. |
05Tradeoffs
| Aspect | You gain | You pay |
|---|---|---|
| Reliability | Crash-proof progress without hand-written checkpoint code. | An additional stateful service (or managed cloud) becomes critical infrastructure. |
| Programming model | Long processes read as ordinary sequential code. | Workflow code must be deterministic; time, randomness and I/O go through engine APIs. |
| Change management | Full, queryable history of every run. | Changing workflow code while runs are in flight needs explicit versioning. |
| Latency | Waits cost no compute while suspended. | Each recorded step adds persistence round-trips. |
06Failure considerations
| Failure mode | Mitigation |
|---|---|
| Non-deterministic workflow code breaks replay after a deploy. | Use the engine's versioning or patching API and replay tests against recorded histories before deploying. |
| Activities with side effects run more than once after a timeout. | Make activities idempotent, using the workflow or activity id as an idempotency key. |
| Event history grows without bound in long-lived workflows. | Periodically continue-as-new to start a fresh history with carried-over state. |
| Large payloads bloat history and slow replay. | Store large data externally and pass references between steps. |
07Implementations
Examples of products and frameworks that implement this pattern. Listed as evidence, not endorsement.
| Implementation | Mechanism |
|---|---|
| TemporalDurable execution engine | Workflows replay from a persisted event history; Activities perform side effects. |
| Azure Durable FunctionsCloud workflow service | Orchestrator functions replay from an event-sourced history. |
| RestateDurable execution engine | A durable journal records handler steps; execution resumes after failure. |
09Requirements that lead here
- A workflow runs for hours or days and must survive restarts and deploys. Primary
- A human must approve before execution continues. Also consider
- I need retries that survive process restarts. Primary
- Multiple services participate in one business transaction. Also consider
- Execution state must persist between steps and across failures. Primary