jonnify·persistence /echo-persistence/champ-accept-tier/recovery-and-replay

Module 2 · Dive 2.3

Recovery & replay.

A crash takes the heap, not the disk. Recovery is two moves: load the last snapshot, then replay the intents recorded after it. The snapshot is a fast starting point; the intent log carries the rest. Step it through and watch the in-heap state rebuild to exactly where it was.

§1

Restore, then replay

interactive
The recovery sequence. On disk: a snapshot, then the intents logged after it. Step forward — crash empties the heap; restore loads the snapshot; each replay applies one intent until the heap is whole again.
on disk snapshot ↯ crash in-heap state
step 0 · running
running · Before the crash the heap is whole — the four snapshot records plus the six intents accepted since. Step forward to crash it, then recover.
§2

The log is the truth

graft.design.md

The snapshot is an optimization, not the source of truth — it just spares you replaying from the beginning. Truth is the snapshot plus the ordered intents after it, so recovery is deterministic: same snapshot, same intents, same state. Measured on the bench, a seed-and-restore lands in single-digit milliseconds and replay runs at over a million intents a second — indicative single-core figures, included only to say the operation is cheap, not slow. The same restore-plus-replay shape returns later for replicas catching up and for the change feed; here it is at its simplest.

§3

References & sources