Durable Workflows

This pillar is about state that must outlive a request — and a process. A saga carries multi-step state across crashes, a trigger turns inbound events into durable work, and a stream fans completed state out to live consumers. All three are declared as typed definitions in your workspace, so what a workflow does is readable from its definition — by you, by the registry tooling, and by a coding agent asked to change it.

The failure mode this pillar exists for is concrete: a checkout charges a card, the process dies before fulfillment confirms, and on restart nobody knows whether to refund. A retry loop cannot answer that question because the state between step three and step four lived only in memory. The storefront checkout saga is the tutorial built around exactly that scenario; the pages in this pillar cover each piece it composes.

The scaffold ships the whole chain running, not as separate demos. A webhook lands on the triggers service (:8093) and enqueues a workers job; the job publishes a UserSettingsCreated message; a saga consumes it and records completion in the durable store you chose. Every link is scaffold code that compiles, and every runtime exposes an HTTP surface you can query to confirm a message actually crossed — which is what makes the chain verifiable step by step instead of trusted end to end.

Use this pillar when an operation spans multiple steps, receives inbound events, or publishes a durable stream for consumers. Start from the failure mode you have:

• State between steps must survive a crash — a multi-step process with compensation: Durable sagas.
• The outside world starts the work — webhooks, dropped files, cron: Triggers & ingress.
• Consumers need the latest state without polling — a typed change-log read over HTTP/SSE: Durable streams.

For the conceptual model behind all three — why state must outlive the process, and how effect-based outcomes differ from a retry loop — read the

The durability model .

Learn, do, look up