Durability starts with a recovery record

Effect is not BEAM. Fibers do not provide private process heaps or OTP restart strategies. A durable operation needs storage and a recovery owner.¶

Use the durability skill to review a design. The durability system page¹⁰ shows the patterns rat-stack ships. These pages separate the book principles from our Effect API mappings.¶

The mappings were written and checked against Effect 4.0.0. The template now pins Effect 4.1.2, and the mappings have not been re-audited against it. Check your own Effect pin before you apply a mapping.¶

Reading order

Effect is not BEAM⁹: Fibers share a runtime; scope³⁵ ownership does not supply isolated heaps or OTP restart strategies.¶
Durable work needs storage¹⁶: A restarted worker⁶⁰ cannot recover intent that existed only in memory.¶
Every task needs an owner⁹: Give child work a lifetime, a failure observer, and a recovery decision.¶
Supervision chooses what restarts¹¹: Restart policy follows dependency shape and bounds repeated recovery.¶
Restart must reconstruct known state⁹: Execution recovery and state recovery need separate contracts.¶
Retry needs idempotent effects¹⁵: Repeating an operation must preserve its intended observable result.¶
Checkpoints follow the promised commit¹⁰: Persist state and progress together when one store can transact both.¶
Replay needs stable inputs⁹: Historical processing must not silently depend on today’s clock or external decisions.¶
Old events must still decode⁹: Retained data needs compatibility rules before recovery depends on it.¶
Dead letters need a return path¹⁵: Exhausted work needs durable evidence, an owner, and deliberate redrive¹⁵.¶
Timeouts bound waiting²⁰: A local timeout²⁰ stops waiting; it does not prove the remote action never happened.¶
Retry load needs a budget¹⁰: One retry owner must control attempts, delay, and aggregate load.¶
Circuit breakers have state¹⁰: A breaker stops doomed calls and controls probes before restoring traffic.¶
Bulkheads isolate scarce capacity¹⁰: Reserve independent capacity for workloads that must not starve each other.¶
Backpressure reaches the producer¹⁰: Bounded consumption helps only when upstream respects waiting or refusal.¶
Admission control protects recovery¹⁰: Refuse or defer work that cannot be served usefully under current load.¶
Steady state recycles resources⁹: Every accumulation needs a deliberate recycling policy.¶
Queries need result bounds⁷: Limit result cardinality⁷ before the driver materializes an oversized response.¶
Failures keep their meaning¹⁰: Expected refusals, infrastructure faults, and defects need different policies.¶
Cleanup can be an idempotent postcondition¹⁰: Already-absent state can be success when absence is the operation’s intended result.¶
Pure cores reduce timeline coupling⁹: Move deterministic rules out of time-dependent actions and shared mutable state.¶
Recovery needs model tests¹⁰: Test sequences of failures and recoveries against explicit invariants.¶
Golden signals expose overload⁹: Measure latency, traffic, errors, and saturation, including failed work.¶
Shared schemas need a transition period⁷: Keep old and new representations usable while consumers migrate.¶
Durable timers need recovery⁷: Persist scheduled intent when losing a worker must not lose its deadlines.¶
Request lifetime is not durability⁹: Worker waitUntil has a shared post-response allowance; required work needs a durable marker and redrive.¶

Existing rat-stack paths

Sources

Read the durability bibliography³³ for books, sections, and checked short quotations. API names describe the Effect 4.0.0 source.¶

Sources

Gray II, James Edward; Tate, Bruce A. Designing Elixir Systems with OTP. Pragmatic Bookshelf, 2019.. Pragmatic Bookshelf. Build a Functional Core; Isolate Process Machinery in a Boundary; Customize Your Lifecycle; Big, Loud Worker-Bees; Add Persistence as a Boundary Service; Test the Boundary. Accessed 2026-10-23.
Nygard, Michael T. Release It!: Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2007.. Pragmatic Bookshelf. §4.4 Unbounded Result Sets; Chapter 5 Stability Patterns: §5.1 Timeouts, §5.2 Circuit Breaker, §5.3 Bulkheads, §5.4 Steady State, §5.5 Fail Fast, §5.6 Handshaking, §5.7 Test Harness, §5.8 Decoupling Middleware. Accessed 2026-10-23.
Effect contributors. Effect 4.0.0. workflow/WorkflowEngine.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.

Last changed 2026-11-08 in fa39fa0. Source on GitHub. Change log.

Linked from

Admission control protects recovery. Refuse or defer work that cannot be served usefully under current load.
Return to the durability index.¶
Agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
Durability starts with a recovery record — A reading order for storage, replay, worker ownership, overload, and recovery tests.
Backpressure reaches the producer. Bounded consumption helps only when upstream respects waiting or refusal.
Return to the durability index.¶
Bulkheads isolate scarce capacity. Reserve independent capacity for workloads that must not starve each other.
Return to the durability index.¶
Change log. What changed in the files served here, newest first.
Durability starts with a recovery record — new page: Initial commit from joelhooks/rat-stack template
Checkpoints follow the promised commit. Persist state and progress together when one store can transact both.
Return to the durability index.¶
Circuit breakers have state. A breaker stops doomed calls and controls probes before restoring traffic.
Return to the durability index.¶
Cleanup can be an idempotent postcondition. Already-absent state can be success when absence is the operation’s intended result.
Return to the durability index.¶
Concurrent work needs an owner and a bound. Limit active work, retain result order, and stop child work when its owning lifetime ends.
For work that must survive a crash, read every task needs an owner and the durability index.¶
Dead letters need a return path. Exhausted work needs durable evidence, an owner, and deliberate redrive.
Return to the durability index.¶
durability. Keep a rat-stack app standing when a provider, pool, or dependency slows down or a worker dies. Use at any I/O boundary, connection pool, provider call, shared waiter, fan-out, flag, gate, or work that can outlive a request, or when asked "what happens when this is slow", "add a timeout", "make this durable", or "what survives a crash".
The durability index gives the reading order.
Durability bibliography. Books, checked short quotations, source limits, and Effect mapping provenance.
Return to the durability index.¶
Durable timers need recovery. Persist scheduled intent when losing a worker must not lose its deadlines.
Return to the durability index.¶
Durable work needs storage. A restarted worker cannot recover intent that existed only in memory.
Return to the durability index.¶
Effect is not BEAM. Fibers share a runtime; scope ownership does not supply isolated heaps or OTP restart strategies.
Return to the durability index.¶
Every task needs an owner. Give child work a lifetime, a failure observer, and a recovery decision.
Return to the durability index.¶
Failures keep their meaning. Expected refusals, infrastructure faults, and defects need different policies.
Return to the durability index.¶
Full agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
Golden signals expose overload. Measure latency, traffic, errors, and saturation, including failed work.
Return to the durability index.¶
Old events must still decode. Retained data needs compatibility rules before recovery depends on it.
Return to the durability index.¶
Pure cores reduce timeline coupling. Move deterministic rules out of time-dependent actions and shared mutable state.
Return to the durability index.¶
Queries need result bounds. Limit result cardinality before the driver materializes an oversized response.
Return to the durability index.¶
Queues, Pipelines, Workflows and K2 do different jobs. Pick a Cloudflare product for work outside a request by the unit you track: a message, a row, a step, or a record in a log.
Next, read Durable work needs storage, then the durability index.¶
Rat Stack lore | rat-stack. Short, source-grounded notes on the ideas and decisions behind rat-stack.
Durability starts with a recovery record — A reading order for storage, replay, worker ownership, overload, and recovery tests.
Recovery needs model tests. Test sequences of failures and recoveries against explicit invariants.
Return to the durability index.¶
Replay needs stable inputs. Historical processing must not silently depend on today’s clock or external decisions.
Return to the durability index.¶
Request lifetime is not durability. Worker waitUntil has a shared post-response allowance; required work needs a durable marker and redrive.
Return to the durability index.¶
Restart must reconstruct known state. Execution recovery and state recovery need separate contracts.
Return to the durability index.¶
Retry load needs a budget. One retry owner must control attempts, delay, and aggregate load.
Return to the durability index.¶
Retry needs idempotent effects. Repeating an operation must preserve its intended observable result.
Return to the durability index.¶
Shared schemas need a transition period. Keep old and new representations usable while consumers migrate.
Return to the durability index.¶
Source change history (log.md). The generated change log as Markdown.
Durability starts with a recovery record — new page: Initial commit from joelhooks/rat-stack template
Steady state recycles resources. Every accumulation needs a deliberate recycling policy.
Return to the durability index.¶
Supervision chooses what restarts. Restart policy follows dependency shape and bounds repeated recovery.
Return to the durability index.¶
Timeouts bound waiting. A local timeout stops waiting; it does not prove the remote action never happened.
Return to the durability index.¶