About This Reference
A small, deliberately narrow technical library about programs that have to survive losing the machine they were running on.

Scope
Four subjects, chosen because they keep turning out to be the same subject seen from different heights: workflow orchestration engines, coroutines as a unit of distributed work, the interpreter and runtime details that make either possible, and the queue behaviour underneath both. Anything that is only a product tutorial is out of scope.
How the material is picked
One test: does the article explain a mechanism that stays true after the current generation of tools is replaced? A piece about how a specific SDK spells a decorator ages out in a year. A piece about why replay requires determinism does not, because the constraint follows from the technique, not from the implementation.
Naming names
Specific products are named throughout (Temporal, Restate, DBOS, Wasmtime, CPython) because naming them is what makes a mechanism concrete instead of abstract, and because a comparison that refuses to name what it is comparing is not worth reading. Where a number appears next to a name, the configuration that produced it is stated in the same paragraph. Selection is editorial: an article is finished when the mechanism is clear, and it goes out without a vendor reading it first.
Who this is written for
The assumed reader is an engineer who has already met the failure. Something died halfway through a batch, a queue redelivered a message that had visibly been processed, or a deploy broke every workflow that was suspended against the previous version of the code. The articles are pitched at the point after that experience: the reader knows the symptom and wants the mechanism underneath it, not a pitch for a product that promises the symptom away.
That pitch has a consequence for tone. There are no analogies to restaurants or post offices, and very little scene-setting. When a claim depends on how CPython lays out a frame or how a broker decides a consumer is dead, the article goes to that layer directly and stays there until the point is made. Readers who want a gentler introduction to any of these subjects are well served elsewhere; this library exists for the layer the gentler introductions stop at.
How the library is structured
Every article stands alone, but the index orders them from the widest subject to the narrowest, and the ordering is meant as a reading path. The orchestration pieces establish what a durable log is and what it costs. The coroutine pieces take the same idea one level down, into what a paused frame actually contains. The runtime pieces go a level below that, into the interpreter details the upper layers quietly depend on. The queue pieces sit underneath everything, because at-least-once delivery is the ground truth every layer above it inherits and none of them can escape.
Cross-references between articles are literal links in the text, not a related-posts widget, on the theory that a reference is only useful at the sentence where the dependency actually appears. If an article never links to another one, that is a statement too: the mechanism it describes genuinely does not depend on the others.
Corrections and revisions
Technical writing about interpreter internals ages badly, and some of what is written here will be wrong at a version boundary. Where an article depends on behaviour that changed in a specific release, the release is named in the text so the claim can be checked instead of trusted. The frame-layout discussion, for instance, is explicit about which details hold for CPython 3.11 and which moved with write-through f_locals in 3.13, because a reader on the wrong version would otherwise watch the example refute the article.
When something turns out to be wrong rather than merely dated, the article is corrected in place and the correction is visible in the text, not silently patched. A revised article keeps its address; nothing is republished under a new URL to look fresh. This is the same policy applied to reading order: the value of a reference is that a claim found here once can be found here again, at the same place, saying the same thing or plainly stating why it no longer does.