In-memory journal

InMemoryJournal stores every event in process memory. It’s the default when you create a system without configuring persistence — fast, zero setup, perfect for tests and dev.

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

// In-memory journal + snapshot store are the DEFAULT — a bare
// ActorSystem.create('demo') already uses them.  To set them explicitly
// (or to swap in other stores later), wire them at creation:
const actorSystemOptions = ActorSystemOptions.create().withPersistence({
  journal:       new InMemoryJournal(),
  snapshotStore: new InMemorySnapshotStore(),
});
const system = ActorSystem.create('demo', actorSystemOptions);

// Now `PersistentActor`s in this system write to the in-memory journal.

It’s also the reference semantics every other journal implementation must match — append-only, monotonic sequence numbers, exact-once delivery to subscribers, concurrency check on expected sequence.

What it does

The journal contract:

interface Journal {
  append<E>(persistenceId: string, events: E[], expectedSeq: number, tags?: string[]): Promise<PersistentEvent<E>[]>;
  read<E>(persistenceId: string, fromSeq: number, toSeq?: number): Promise<PersistentEvent<E>[]>;
  highestSeq(persistenceId: string): Promise<number>;
  delete(persistenceId: string, toSeq: number): Promise<void>;
  persistenceIds(): Promise<string[]>;
  readonly events?: JournalEventBus;
  close?(): Promise<void>;
}

InMemoryJournal implements all of this with a Map<string, PersistentEvent[]> internally. Operations are:

• append — push events onto the stream’s array. Concurrency check on expectedSeq (throws JournalConcurrencyError if the current head doesn’t match).
• read — slice the array by sequence number range.
• highestSeq — read the last entry’s seqNr (or 0).
• delete — splice off the prefix.
• persistenceIds — iterate the Map’s keys.

Every append also publishes the event to the in-process JournalEventBus — so push-based queries (see Push-based query) work in real time without polling.

When to use it

Three legitimate cases:

1. Tests — fast, no IO, no cleanup needed between tests. Spin up a fresh system, do your assertions, tear down.
2. Development — when you don’t want to bother with a SQLite file during local iteration.
3. Throwaway demos — when the data isn’t supposed to survive.

For anything that needs to persist across restarts, switch to SQLite or Cassandra.

Test pattern

import { describe, it, beforeEach, afterEach } from 'bun:test';
import { TestKit } from 'actor-ts';

describe('OrderActor', () => {
  let tk: TestKit;

  beforeEach(() => {
    tk = TestKit.create();   // in-memory journal + snapshot store by default
  });

  afterEach(async () => { await tk.shutdown(); });

  it('replays events on restart', async () => {
    const probe = tk.createTestProbe();

    // Create + send some commands
    let order = tk.system.spawnAnonymous(() => new OrderActor('order-1'));
    order.tell({ kind: 'place', sku: 'book-1' });
    order.tell({ kind: 'place', sku: 'book-2' });
    await probe.expectMessage({ kind: 'placed', sku: 'book-2' });

    // Stop + re-spawn — same persistence ID
    await tk.system.stop(order);
    order = tk.system.spawnAnonymous(() => new OrderActor('order-1'));
    order.tell({ kind: 'view', replyTo: probe });

    // Recovered state should reflect both placed events
    await probe.expectMessage({ items: ['book-1', 'book-2'] });
  });
});

A fresh InMemoryJournal per test (via per-test TestKit) makes each case isolated — no state leakage between tests.

What it doesn’t do

Data dies with the process

The journal stores everything in a Map. When the process exits, the Map is gone. This is fine for tests and dev — but never deploy a production app with the in-memory journal. Restart = total data loss.

Not shared across systems

const j = new InMemoryJournal();
const optionsA = ActorSystemOptions.create().withPersistence({ journal: j });
const systemA = ActorSystem.create('a', optionsA);
const optionsB = ActorSystemOptions.create().withPersistence({ journal: j });
const systemB = ActorSystem.create('b', optionsB);
// ↑ same instance, but in a real multi-process setup each process
//   has its own — the in-memory data isn't shared across them.

Sharing the same InMemoryJournal instance across systems in one process works, but doesn’t help in any multi-process deployment. For shared journal in a cluster, use Cassandra.

Unbounded memory growth

The journal stores every event forever (until you call delete). A long-running test that emits thousands of events per second will grow the journal’s memory linearly. For long-running benchmarks, either snapshot aggressively + call delete after each snapshot, or use SQLite which flushes to disk.

Switching to a real journal

// Before (test / dev) — in-memory is the default:
const devOptions = ActorSystemOptions.create().withPersistence({
  journal: new InMemoryJournal(),
});
const system = ActorSystem.create('app', devOptions);

// After (production):
import { SqliteJournal, SqliteJournalOptions } from 'actor-ts';
const sqliteJournalOptions = SqliteJournalOptions.create().withPath('/var/lib/my-app/events.db');
const prodOptions = ActorSystemOptions.create().withPersistence({
  journal: new SqliteJournal(sqliteJournalOptions),
});
const prodSystem = ActorSystem.create('app', prodOptions);

No code changes inside actors — the Journal interface is the same. Just swap the implementation.

This is why we say “use in-memory for tests and dev” — the production switch is one line, and the test suite continues to run against fast in-memory journals.

Where to next

• Persistence overview — the bigger picture.
• SQLite journal — the single-node production default.
• Cassandra journal — for multi-node production.
• PersistentActor — what’s writing the events.
• Snapshot stores — In-memory — the companion in-memory snapshot store.