Snapshots are recovery boundaries

A snapshot is not just a way to make replay faster. In ledger systems, it is a point where recovered state must remain explainable.

Append-only logs are valuable because they preserve history. They also create an operational question: how much history must be replayed before the system can safely resume?

Snapshots answer that question, but their role is bigger than performance. A snapshot defines a durable recovery boundary.

Replayability is a correctness property

If a system can rebuild state from durable history, it has a way to explain current balances. If replay is nondeterministic or incomplete, the system may restart but still fail to prove why a balance has its value.

For value exchange systems, recovery is not finished when the process starts. Recovery is finished when the financial state, operation identities, pending holds, rejected records, and history indexes are consistent with the durable record.

Snapshots reduce the recovery window

A system can replay from the beginning forever, but that becomes impractical as history grows. A snapshot lets recovery begin from a known state and then apply the log tail after that point.

The useful question is not only “how fast is recovery?” It is also “what exactly does this snapshot prove, and what must still be replayed?”

Recovery must rebuild more than balances

Balances are only one part of the ledger state. A practical ledger also needs operation identity, pending reservations, rejected outcomes, account metadata, and query indexes.

If those supporting structures are not rebuilt consistently, the system can show the right number but still answer important operational questions incorrectly.

Snapshots should be boring under pressure

Recovery usually matters when the system is already under stress: a crash, restart, deploy, disk event, or failover. That is why snapshot behavior should be simple to reason about and easy to test.

The private-preview posture for TulaDB is to make this evidence visible: what is included in the snapshot, what is replayed, and how recovered state is checked.

What to review in private preview

Reviewers should run crash and restart tests, inspect recovery logs, compare balances before and after restart, verify rejected records, and check pending reservation behavior after replay.