Durable Execution
Durable execution persists every workflow step and its results as it progresses, so a crashed process resumes from the recorded state instead of restarting from scratch or losing work.
Definition
Durable execution engines (Temporal, Restate, Azure Durable Functions) execute workflows as event-sourced state machines: each step, its input, and its output are journaled before progression. On failure, a new worker replays the journal, deterministically reconstructing state and re-executing only uncompleted steps. Business logic reads like ordinary sequential code while execution survives crashes, deploys, and outages lasting hours.
Context and scope
Applied to multi-step business processes with strict reliability: payments, provisioning, order orchestration, batch jobs that cannot restart cleanly.
Common misconceptions
- It is just retry logic — retries re-execute entire operations with side effects; durable execution records progress and resumes exactly where it stopped
- Determinism is a nice-to-have — replay requires deterministic workflow code; nondeterminism breaks resume and is the first bug class new users hit
- The engine replaces message queues — queues are transport; durable execution adds state, timers, compensation, and visibility on top of any transport
Anti-patterns
- Calling non-deterministic functions — random, current time, thread sleeps — inside workflow code and breaking replay
- Putting long-running business logic in activities with huge timeouts instead of decomposing into resumable steps
- Retrying non-idempotent activities without idempotency keys and double-charging during failure windows
Related concepts
Authoritative source
What it is
A workflow that runs for hours or days cannot assume its process survives. Durable execution makes survival irrelevant: the journal of completed steps is the truth, and any worker can continue from it.
How it works
The workflow function executes under an engine interceptor. Each activity invocation and its result are recorded before proceeding. On resume, the replay feeds recorded results to the same code until it reaches the first unrecorded step, which executes for real. Timers, signals, and child workflows journal the same way. Workers are stateless; the journal is the state.
When to use it
Processes whose restart-from-zero is expensive or incorrect: financial orchestration, infrastructure provisioning, long approvals. Overkill for request-response and idempotent replays-from-scratch jobs.
Pitfalls
Workflow code must be deterministic and fast — side effects and waits belong in activities, and new users fight this constantly. Versioning running workflows across code deploys needs versioned workflow definitions or version-tolerant code. Activity retries still demand idempotency at the effect site: the engine guarantees single logical execution, not single physical side effect.