In-Memory-Snapshot-Store

InMemorySnapshotStore hält Snapshots in einer Map<persistenceId, Snapshot[]> im Prozess-Speicher. Wie InMemoryJournal ist es der Default, wenn kein Snapshot-Store konfiguriert ist — null Setup, ideal für Tests, niemals in Produktion verwenden.

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

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

Was es tut

Implementiert das SnapshotStore-Interface — save, loadLatest, deleteUpTo. Jede persistenceId mappt auf ein Array von Snapshots, geordnet nach Sequenznummer.

• save(pid, snapshot) — an das Array der pid anhängen.
• loadLatest(pid) — den Snapshot mit der höchsten seq zurückgeben oder None.
• deleteUpTo(pid, seqNr) — Snapshots mit seq ≤ seqNr abschneiden.

Die Implementierung ist Referenz-Semantik — jeder andere Snapshot-Store muss dieses Verhalten erfüllen (modulo Persistenz- / Verschlüsselungs- / Kompressions-Spezifika).

Wann verwenden

• Tests — schnell, kein IO, sauberer Teardown pro Test.
• Dev — wenn du keine echte Snapshot-Datei zwischen Runs herumliegen haben willst.
• Referenz für benutzerdefinierte Implementierungen — lies den Source für den Vertrag.

Wann NICHT verwenden

Produktion

Daten sterben mit dem Prozess. Ein Neustart verliert jeden Snapshot, sodass die Recovery jedes Mal auf vollständigen Event-Log-Replay zurückfällt — was den Sinn von Snapshots zunichtemacht.

Lange laufende Tests

Snapshots akkumulieren im Speicher. Ein Benchmark, der über einen Run 1M Snapshots macht, lässt die Map linear wachsen. Für lange Tests konfiguriere deleteUpTo-Cleanup oder verwende den SQLite-Store mit :memory:.

Wie geht’s weiter

• Snapshots — die Policy / Mechanik.
• SQLite-Snapshot-Store — Single-Node-Produktion.
• Cached-Snapshot-Store — wickle jeden Store mit einem In-Process-Cache ein.