Articles: Durable Execution, Orchestration and Coroutines
Bar length is reading time and offset is roughly where the subject sits between mechanism and operations. There are no categories to click through; the whole library is below.
- 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.
The two subjects most of this comes back to
Workflow orchestration
What an orchestration engine records, what it guarantees, and the rewrite it asks for in exchange.
- The durable log
- Activity and workflow code
- History size and retention
- Where the guarantee stops
Distributed coroutines
Suspension as a value: what a paused frame is made of, and when moving one is cheaper than restarting.
- Frames and offsets
- Serialisable locals
- Code-version pinning
- Exactly-once resume
How the library is organised
Seven articles is a deliberate size, not a starting point. Each one covers a mechanism that stays true after the current generation of tools has been replaced, which rules out most of what gets written about this subject: SDK tutorials age out at the next minor release, and a comparison table is stale the week a competitor ships.
Read across them and the same shape keeps appearing at different heights. An orchestration engine records completed steps so a crash resumes instead of restarting. A distributed coroutine records a paused frame for the same reason. Both are asking the same question — where does progress get written down, and who is allowed to write it — and both pay for the answer with a restriction on how the supervised code may be written.
Underneath both sits a message queue, which is why two of the seven are about queue and runtime behaviour, not orchestration. An engine that redelivers a step is inheriting at-least-once delivery from the layer below it, and a team that has not internalised the queue's failure modes will meet them again one abstraction up, with less visibility.
The ordering inside the index is deliberate as well. Longest read first is not a ranking of importance; it puts the widest subject at the top so that a reader arriving cold meets the full argument before the specialised pieces that assume it. Someone who already knows why a durable log exists can start anywhere; the horizontal offset is there precisely so that a reader hunting for interpreter detail can jump straight to the left-most bars and skip the orchestration layer entirely.
One reading habit the layout rewards: pick a pair of bars that nearly touch and read them together. The orchestration piece next to the queue piece is the clearest example: the first explains what an engine promises about redelivered work, the second explains why the broker underneath will redeliver it in the first place, and each argument is roughly half as convincing on its own. The pairings are not marked, deliberately; noticing that two articles are answering each other is most of what the pairing teaches.
What is not covered
No getting-started guides, no vendor comparisons with scores, and no benchmarks produced here. Where numbers appear they are attributed and the configuration that produced them is named, because an unattributed performance figure for WebAssembly or for an orchestration engine is a number attached to an unnamed setup.
There is also no coverage of the operational side: capacity planning, cost modelling, multi-region topology. Those are real subjects and they are somebody else's; this library stops at the point where the mechanism is clear and the trade-off is stateable.
About this index
In what order should these be read?
Top to bottom works, because the index is ordered from the widest subject to the narrowest. If you are evaluating an orchestration engine, start with the workflow orchestration piece and then the queue failure modes: those two cover most of what goes wrong in production.
Why is there no category navigation?
Seven articles do not need a taxonomy. A filter bar over seven items costs a click and hides the smallest ones; one page listing all of them costs nothing and makes the whole scope visible at once.
What do the bar length and offset mean?
Length is reading time, so a long bar is a long article. Horizontal offset places the subject roughly between mechanism on the left and operations on the right: interpreter internals sit left, queue behaviour sits right. It is a reading aid, not a measurement.
How often is anything added?
Irregularly, and only when there is a mechanism worth writing down. A subject that changes at a version boundary gets revised in place, not reposted, with the release named in the text so the claim stays checkable.
Are the code examples runnable?
The Python examples are, on the version named next to them. Where an example depends on interpreter internals that moved (the frame layout in 3.11, write-through f_locals in 3.13), the version is stated in the surrounding prose, because the same snippet genuinely behaves differently across those boundaries.