Checkpoint

Forge

A recorded point a task can resume from, so a failure does not mean repeating everything before it.

What is a checkpoint?

A checkpoint is a recorded point in a task that execution can resume from. It holds enough state to continue, meaning which steps have committed and what each of them returned. A failure after a checkpoint costs the work since that point rather than the whole task.

Why a long task without checkpoints is an all-or-nothing task

A three hour reconciliation that fails at the final step has to begin again, and the second attempt repeats every write the first one committed. That is where duplicate payments and double-posted journals come from. Checkpointing and idempotency are therefore engineered as one problem. The length of the task determines whether any of this matters. Short tasks can be retried whole; anything touching several systems in sequence cannot.

  • Checkpoints reduce the cost of a failure to the work since the last one.
  • They make a retry safe to attempt without reviewing the whole task.
  • Recorded state tells an operator exactly where the task reached.
  • Long multi-system tasks are impractical to attempt again from the beginning.

How a checkpoint works

  • Boundaries are placed where committed state changes, usually after each external write.
  • At each boundary the task records which steps completed and what they returned.
  • That record is written durably before the next step is attempted.
  • On resumption the task reads its last checkpoint and continues from there.
  • Steps already committed are skipped by reference to their idempotency keys.
  • Checkpoint records are retained with the task for the length of its audit period.

How a checkpoint is evaluated

Checkpointing is tested by interrupting a task rather than by inspecting its design. Measure the following under deliberate interruption:

  • proportion of interrupted tasks resuming without manual intervention
  • work repeated after resumption, measured in committed steps
  • duplicate external effects produced by a resumed task
  • latency added by writing each checkpoint
  • age of the oldest checkpoint a task can still resume from

Limitations, risks and common failure modes

  • Boundaries are placed at convenient code points rather than after external writes.
  • A resumed task replays a step whose external effect was never recorded.
  • Checkpoint state references documents that have changed since the interruption.
  • A task resumes against a session or a token that has since expired.

All 315 terms