Checkpoints follow the promised commit

A consumer position and its materialized state must agree. Acknowledge processing only after the promised processing completes.

allowing a single stateful transaction to atomically update both the state and input offsets.

Source: Q1333; B533.

Failure it prevents

Progress advances without its state, or state commits while replay still reapplies the event.

Our Effect 4.0.0 reading

SqlClient.withTransaction covers its database boundary. Stream.runForEach expresses handling only. Broker acknowledgement and remote transactions need their own protocol.

Source: packages/effect/src/sql/SqlClient.ts, packages/effect/src/Stream.ts.

How to check

Crash before and after state commit and acknowledgement. Redeliver and compare state with the expected checkpoint. This check is our proposal. The books do not prescribe it.

Continue with Retry needs idempotent effects14, Dead letters need a return path14.

Connect this to the existing rat-stack guidance23.

Use the durability skill for the full review. Return to the durability index34.

Sources

  1. Bellemare, Adam. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. O’Reilly, 2020.. O’Reilly. Chapter 3 Communication and Data Contracts; Chapter 6 Deterministic Stream Processing; Chapter 7 Stateful Streaming; Chapter 9 Microservices Using Function-as-a-Service; Chapter 14 Supportive Tooling. Accessed 2026-10-23.
  2. Effect contributors. Effect 4.0.0. sql/SqlClient.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.
  3. Effect contributors. Effect 4.0.0. Stream.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.

Last changed 2026-10-23 in 58dc623. Source on GitHub. Change log.

Linked from

  1. Agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.

    Checkpoints follow the promised commit — Persist state and progress together when one store can transact both.

  2. Change log. What changed in the files served here, newest first.

    Checkpoints follow the promised commit — new page: docs(lore): land the durability wiki pages and bibliography

  3. 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".

    Couple state and checkpoint where one transaction can own both.

  4. Durability starts with a recovery record. A reading order for storage, replay, worker ownership, overload, and recovery tests.

    Checkpoints follow the promised commit: Persist state and progress together when one store can transact both.¶

  5. Durable work needs storage. A restarted worker cannot recover intent that existed only in memory.

    Continue with Every task needs an owner, Checkpoints follow the promised commit.¶

  6. Full agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
  7. Rat Stack lore | rat-stack. Short, source-grounded notes on the ideas and decisions behind rat-stack.

    Checkpoints follow the promised commit — Persist state and progress together when one store can transact both.

  8. Recovery needs model tests. Test sequences of failures and recoveries against explicit invariants.

    Continue with Checkpoints follow the promised commit, Circuit breakers have state.¶

  9. Retry needs idempotent effects. Repeating an operation must preserve its intended observable result.

    Continue with Checkpoints follow the promised commit, Cleanup can be an idempotent postcondition.¶

  10. Source change history (log.md). The generated change log as Markdown.

    Checkpoints follow the promised commit — new page: docs(lore): land the durability wiki pages and bibliography