Durable Execution Explained: A Field Guide to the Moving Parts
An independent technical reference on programs that keep their place across process restarts. Durable execution patterns explained from the mechanism up: the log underneath them, the constraints each one imposes, and the costs that do not appear on a vendor comparison page. A guide for engineers deciding whether the trade is worth making.
- Orchestrationorchestration.logWorkflow Orchestration Tools: What the Engine Actually Does
What a workflow orchestration engine really guarantees, what the durable log costs to keep, and the rewrite it demands in exchange.
- Coroutinescoroutines.logPython Coroutines Across Machines: Async, Await, Distributed
How Python coroutines become distributed work: what a paused frame contains, which locals survive serialisation, and where it breaks.
- Foundationsorchestration.logWhere a New Programming Model Comes From, and What It Costs
Where the durable execution programming model came from, and why every engine converges on a log plus a restriction on your code.
- Runtimeruntime.logHow CPython Prints a Python Stack Trace: Traceback Internals
How CPython turns a raised exception into a printed stack trace: frames, tracebacks, and the caret positions added by PEP 657.
- Runtimeruntime.logWasm Performance: Profiling Golang and Reading Benchmark Results
Why WebAssembly performance is hard to measure honestly, and how profiling support in Wasmtime changes what can be observed.
- Coroutinescoroutines.logDistributed Coroutines: Suspending Here and Resuming Elsewhere
Distributed coroutines treat suspension as a value: what that buys over message passing, and the versioning problem it introduces.
- Queuesqueues.logWhen Queues Stop Working: A Taxonomy of Failure Modes
The queue failure modes that surface in production: redelivery, poison messages, consumer-liveness guesses and head-of-line blocking.
What is durable execution, and what is it not
A program with an ordinary bug fails loudly and you fix the bug. A program that is killed halfway through a four-hundred-item batch fails quietly and leaves you a much worse problem: not an error, but an unknown. Which items were processed? The only component that knew is gone.
Durable execution is the answer to exactly that class of failure and to nothing else. The runtime writes down each completed step outside the process, so that a replacement process can read the record and continue instead of starting over. Everything else in the category — the SDKs, the consoles, the retry policies, the signalling APIs — is machinery around that one durable log.
So the short answer to what is durable execution is: a step-by-step record kept outside the process, plus a rule about who may write to it. Everything a vendor adds on top is convenience around that record.
It is worth stating what is not included, because the marketing tends to blur it. Durable execution does not make side effects happen exactly once at their destination. It does not repair bad logic. It does not remove the need for idempotency keys at your boundaries. And it is not free: every engine in this space buys its guarantee with a restriction on how you are permitted to write the code it supervises. Any guide that presents the guarantee without the restriction has explained half of it.
The three durable execution patterns, explained
The engines differ more than their landing pages suggest, and the difference is which of three mechanisms they use. Knowing which one you are adopting predicts most of the friction. The durable execution patterns below are not marketing categories; each one is a different answer to the question of where progress is written down.
| Pattern | How progress is kept | What it constrains |
|---|---|---|
| Step recording | Each named side effect writes its result to a log before the next one runs | Every effect must be a separately addressable unit with serialisable arguments |
| Replay | The function body is re-executed; completed steps return their recorded values instead of running | The body must take the same path twice: no clocks, no randomness, no ambient I/O |
| Journalled suspension | The paused frame itself is written down and rebuilt on resume | The locals at each suspension point must be serialisable, and the code version must be pinned |
Those three durable execution patterns are not interchangeable in practice. Replay is the most widely deployed and puts the heaviest constraint on your dependency tree, because determinism has to hold transitively through libraries you did not choose. Journalled suspension narrows that requirement considerably and introduces a versioning problem in its place. Step recording is the least magical and the most verbose.
A guide to reading the claims
Four questions separate a real evaluation from a feature-table comparison, and none of them are answered on a pricing page. Treat this as the short version of the guide: if a vendor answers all four plainly, the rest of the documentation is probably honest too.
- Which of the three mechanisms is this, and therefore what am I being asked to stop doing in the supervised code?
- How large does the history get, how long is it kept, and who pays for reading it back on every resume?
- What happens to work suspended against the previous deploy: is there a pinning story, or does a release break in-flight executions?
- When the guarantee is described as exactly-once, exactly once as observed by what: the log, or the payment provider?
The honest summary of what is durable execution good for: processes with multiple steps, real outside effects, and a runtime measured in minutes or longer, where restarting from the beginning is either expensive or unsafe. For a three-second idempotent handler it is bookkeeping you pay for and never read. That boundary, once explained clearly, decides most adoption arguments before anyone compares feature tables.
What this site covers
Four subject areas, all of them mechanism-level, not tutorial: workflow orchestration engines and what they really guarantee, coroutines as a unit of distributed work, the CPython and WebAssembly runtime details that make either possible, and the queue failure modes that sit underneath all of it.
There is no advertising here, nothing is sponsored, and no vendor has reviewed any of it. Where a specific product is named it is because naming it makes the mechanism clearer.
Common questions
What is durable execution, in one sentence?
Durable execution is running a program so that its progress is recorded outside the process, step by step, so a crash resumes it at the last recorded step instead of restarting it from the beginning.
Is durable execution the same thing as a retry?
No. A retry runs the whole unit of work again and needs the whole unit to be safe to repeat. Durable execution records each step as it completes, so a resume repeats only the step that was in flight. The distinction matters most when the earlier steps had side effects you cannot repeat.
Does durable execution give exactly-once side effects?
It does not, and no engine on the market does. What it guarantees is that the workflow observes each recorded step exactly once. If a step charged a card and the process died before the result was written, the step runs again; the idempotency key at the boundary is still the application’s responsibility.
What are the common durable execution patterns?
Three recur. Step recording, where each side effect is a named unit whose result is logged. Replay, where the function body is re-executed and completed steps return their recorded values. And journalled suspension, where the runtime stores the paused frame itself. Each puts a different constraint on how the code may be written.
What has to change in existing code to adopt it?
Every outside effect has to become something the runtime can name and record separately from the code that decides when to call it. Pure computation usually stays as it is. The size of the change is roughly proportional to how much I/O the process does, not to how long the process is.
Which failures does it not help with?
Logic errors, bad data and a dependency that is simply wrong. Durability makes a process survive infrastructure failure; it faithfully re-runs a mistake as often as you ask it to.