Checkpoint

Why it exists

Long-running systems cross process boundaries, wait on external actors, and repeat work after uncertainty. Checkpoint gives engineers a precise way to reason about one part of that reliability problem.

The naive implementation

run task
  → keep progress in memory
  → assume the call succeeded
  → continue

What breaks

The process can disappear between an external effect and the local record of that effect. On recovery, the system no longer knows what happened. Retrying blindly may duplicate work; skipping may lose it.

How it works

observe durable state
        ↓
make one bounded decision
        ↓
record evidence + outcome
        ↓
continue or recover

What it does not guarantee

This concept is not a complete reliability strategy. It does not make external side effects transactional, prove semantic correctness, or remove the need for monitoring and evaluation.

Related concepts

Use it in a pattern