jonnify·persistence /echo-persistence/foundations/champ-accept-tier

Module 2 · Chapter I — Foundations

Champ, the accept tier.

The first tier says yes fast. Champ holds the outbox in a persistent in-heap structure and writes a snapshot to disk every K records, so the accept path runs at heap speed while a single fsync covers a whole interval. This module takes Champ apart in three moves — the structure, the checkpoint dial, and recovery — each by working the figure, not reading a benchmark.

The Champ lifecycle. Accept, checkpoint, crash, recover. Tap a stage to read it, or run the loop.
1 · acceptin-heap CHAMP 2 · checkpointsnapshot every K · fsync ↯ crashlose the heap 3 · recoverrestore + replay
readout · Tap a stage, or run the loop. Accept is heap-fast; the checkpoint is the only disk cost, amortized over K; recovery rebuilds from the last snapshot plus the intents after it.
§1

Why an accept tier

graft.design.md

A strict, replicated commit is expensive, and you do not want every enqueue to wait for it. Champ’s job is to absorb the write at heap speed and bound the exposure, leaving the durable, replicated commit to the second tier on its own schedule. The bound is K: the records accepted since the last snapshot are the only ones a crash can take, so K is the loss window in records and the throughput dial at once.

Three properties make that work, and each is a dive. The structure is persistent, so a snapshot is a cheap reference to an immutable version rather than a copy. The checkpoint is periodic, so one fsync serves K records. And recovery is restore-plus-replay, so a lost heap is rebuilt from the last snapshot and the intent log after it — fast, and without the commit tier.

§2

The three dives

module 2
Dive 2.1

The in-heap structure

Why a persistent map: insert a key and watch the new version share every untouched node with the old — structural sharing is what makes a snapshot nearly free.

 Dive 2.2

The checkpoint dial

K is the loss window. Watch records accumulate against the checkpoint; set K and see the at-risk gauge and the fsync rhythm move together.

 Dive 2.3

Recovery & replay

A crash, then restore from the last snapshot and replay the intents after it. Step the sequence and see the state come back.
§3

Build & check

What you build

A back-of-envelope sizing note for one queue: pick an acceptable loss window in records, set K to it, and state in a sentence what that costs (snapshot frequency) and what it buys (accept latency). No absolute throughput required — just the direction each choice moves.

Check

Explain, without numbers, why a snapshot of a persistent structure does not copy the whole map; and describe what recovery reads, in order, after a crash. If you can narrate restore-then-replay, you have the tier.

§4

References & sources