In-memory snapshot store

InMemorySnapshotStore keeps snapshots in a Map<persistenceId, Snapshot[]> in process memory. Like InMemoryJournal, it’s the default when no snapshot store is configured — zero setup, ideal for tests, never use in production.

import { InMemorySnapshotStore, PersistenceExtensionId, ActorSystem } from 'actor-ts';

const system = ActorSystem.create('demo');
system.extension(PersistenceExtensionId).configure({
  journal:       new InMemoryJournal(),
  snapshotStore: new InMemorySnapshotStore(),
});

What it does

Implements the SnapshotStore interface — save, loadLatest, deleteUpTo. Each persistenceId maps to an array of snapshots ordered by sequence number.

• save(pid, snapshot) — append to the pid’s array.
• loadLatest(pid) — return the highest-seq snapshot, or None.
• deleteUpTo(pid, seqNr) — splice off snapshots with seq ≤ seqNr.

The implementation is reference semantics — every other snapshot store must match this behavior (modulo persistence / encryption / compression specifics).

When to use it

• Tests — fast, no IO, clean teardown per test.
• Dev — when you don’t want a real snapshot file lying around between runs.
• Reference for custom implementations — read the source for the contract.

When NOT to use it

Production

Data dies with the process. A restart loses every snapshot, so recovery falls back to full event-log replay every time — defeats the point of snapshots.

Long-running tests

Snapshots accumulate in memory. A benchmark that takes 1M snapshots over a run grows the Map linearly. For long tests, configure deleteUpTo cleanup or use the SQLite store with :memory:.

Where to next

• Snapshots — the policy / mechanics.
• SQLite snapshot store — single-node production.
• Cached snapshot store — wrap any store with an in-process cache.