Snapshots: preserve a committed prefix and its meaning

Choose an index s that has been committed and applied. The snapshot must represent exactly the state after applying the command prefix through s, from a compatible earlier state. Concurrent snapshotting can use a database's consistent snapshot mechanism, copy-on-write state, or an explicitly serialized application boundary. The implementation must preserve a coherent cut rather than letting unrelated fields come from different applied positions. A local log entry beyond commitment cannot be made irrevocable by placing its speculative effect into a snapshot.

Record the last included index and its term so the remaining log can still perform consistency checks at the compacted boundary. Include the configuration associated with the snapshot's state according to the membership protocol, not whichever membership the operator happens to prefer at restore time. Client-session and request-deduplication information may also be required to preserve retry behavior. A restored business state without the corresponding deduplication ledger can replay an already executed request even though consensus history itself was retained.

The snapshot and its recovery metadata must become durably discoverable before the covered log records are reclaimed. Exact file and manifest operations depend on the storage engine, but the recovery invariant is general: after every crash cut there must remain a complete usable snapshot plus the log continuation it needs. Writing a snapshot file, deleting old logs, and only then making the new file recoverable leaves a dangerous gap. Checksum and format validation detect damaged inputs; they do not establish ordering or membership correctness by themselves.

A follower behind the leader's retained prefix may need snapshot installation instead of ordinary AppendEntries replay. It must install a compatible snapshot atomically with its local recovery state and then accept the correct suffix. Protocol rules determine whether an already matching local suffix can be retained or must be discarded. Installation must not roll application backward or combine an older snapshot with a newer incompatible database. An outdated snapshot request can be ignored according to the implementation rather than blindly replacing a replica's later state.

Frequent snapshots consume serialization, storage bandwidth, and transfer resources; infrequent snapshots retain a larger log and make catch-up more expensive. Keep enough useful suffix for common follower delays if the storage budget permits, and measure both snapshot duration and application interference. A snapshot can be larger than the commands it replaces when current state is large. The reason to take it is a defined recovery and retention tradeoff, not an assumption that every checkpoint compresses data.

The queue lab supplies only a retention-pressure analogy. Reset, explicitly set arrival four and service three, predict growth from four retained units, then Play or Step. For a separate draining example Reset and explicitly set arrival two and service three before predicting and playing. Rate edits retain elapsed time and recompute the fixed-rate curve from four initial units. The model does not create snapshots, delete prefixes, preserve metadata, or install follower state. Treat service as an idealized removal capacity, not a literal snapshot-completion event.