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 { ActorSystem, ActorSystemOptions } from 'actor-ts';
import { InMemoryJournal, InMemorySnapshotStore } from 'actor-ts/persistence';

// In-memory stores are the default; shown here explicitly:
const actorSystemOptions = ActorSystemOptions.create().withPersistence({
  journal:       new InMemoryJournal(),
  snapshotStore: new InMemorySnapshotStore(),
});
const system = ActorSystem.create('demo', actorSystemOptions);

What it does

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

• save(persistenceId, seq, state, options?) — insert into the pid’s array, replacing any existing entry at the same sequence number.
• loadLatest(persistenceId, options?) — return the highest-seq snapshot, or None.
• loadBefore(persistenceId, seq, options?) — return the newest snapshot with sequenceNr < seq, or None.
• delete(persistenceId, toSeq) — splice off snapshots with seq ≤ toSeq.

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

Retention

keepN bounds how many snapshots are kept per persistenceId; older ones are pruned on save. <= 0 keeps everything.

import { InMemorySnapshotStore, InMemorySnapshotStoreOptions } from 'actor-ts/persistence';

const inMemorySnapshotStoreOptions = InMemorySnapshotStoreOptions.create().withKeepN(3);
const snapshotStore = new InMemorySnapshotStore(inMemorySnapshotStoreOptions);

Unset, it keeps every snapshot — and that is the one place this store deliberately differs from the family, where every persistent store defaults to keepN: 3. This is the store you get when nothing is configured, so a default bound would change what every unconfigured application retains without anyone asking for it. Opt in explicitly instead.

Re-saving at a sequence number that already exists replaces that snapshot rather than appending a second one, matching the relational stores’ (persistence_id, sequence_nr) primary key.

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 by default. A benchmark that takes 1M snapshots over a run grows the Map linearly. For long tests, set keepN, call delete yourself, 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.