jonnify·persistence /echo-persistence/local-store/replay-and-recovery

Module 6 · Chapter II — The local store

Replay & recovery.

Three operations that look unrelated — booting a fresh process, catching up a replica, feeding a subscriber changes — are the same operation: replay the immutable log from some LSN forward to the head. Only the starting LSN and the source of the bytes differ. This module shows the one mechanism behind all three, by working the figure, not reading a benchmark.

One log, three replays. The same commit log, read by three operations — each just starts at a different LSN and applies forward to the head. Tap one.
readout · Tap an operation. Each replays the log from a starting LSN to the head — boot from the last snapshot, a replica from its own LSN, a subscriber from its cursor. The apply step is identical; only where you start differs.
§1

Recovery is not a special case

graft.design.md

Chapter II established that the log is append-only and immutable, so the state at any LSN is the log folded to that point, and old roots stay valid. The payoff this module collects is that recovery stops being special. Rebuilding a crashed process, bringing a lagging replica current, and streaming changes to a consumer are not three subsystems — they are one fold, apply(commit) repeated from a starting LSN to the head, parameterized only by where you begin and whether the bytes are local or pulled from object storage.

That single idea is the through-line of the three dives: the unified replay, then its two most important instances — green boot for zero-downtime deploys, and replica catch-up, which is the same machine the change feed exposes to the world.

§2

The three dives

module 6
Dive 6.1

One log, three replays

Three cursors on one log. Advance each to the head and watch the apply step be identical — recovery, replica, and feed are the same fold from different starts.

 Dive 6.2

Green boot

Blue serves while green boots: seed from the snapshot, replay the tail to the head, then cut traffic over. Zero downtime, because the log is the truth.

 Dive 6.3

Replica catch-up & the feed

A replica pulls segments after its LSN and applies them until the lag is zero — and the change feed is that same ordered stream, exposed to subscribers.
§3

Build & check

What you build

Write the one function signature the whole module reduces to — something like replay(from_lsn, apply_fn) — and, in a sentence each, say what from_lsn is for green boot, replica catch-up, and the feed. No numbers; the unification is the point.

Check

Answer without code: what makes replay deterministic, and why does that let a replica and the primary agree byte-for-byte? If you reach “same start, same ordered commits, same state,” you have the module.

§4

References & sources