jonnify·persistence /echo-persistence/rust/the-in-memory-feed

Module 8 · Dive 8.3

The in-memory feed.

The Rust engine serves its change feed from memory: recent commits live in a fixed-size ring, broadcast to every subscriber at its own cursor — a hit is an O(1) read, no disk, no network. A subscriber that keeps up never touches storage. One that falls behind the ring’s window is not dropped: it falls back to the durable segments in object storage, catches up to the window edge, and rejoins. Commit faster than a subscriber reads and watch it fall off — then recover.

§1

Broadcast, window, fallback

interactive
An in-memory feed with a safety net. The writer appends to a five-slot ring; subscribers A and B read from it. Commit without letting B read and its cursor drifts off the window — then a B read falls back to durable segments to catch up.
in-memory ring · last 5 commits writer appends segments · object storage every commit, durable — the fallback when a subscriber falls behind
readout · A and B start at the head. Commit a few times without letting B read — the ring slides and B’s next LSN ages out. Then press “B reads”: it falls back to segments, catches up to the window edge, and rejoins.
§2

Memory speed, durable floor { id="why" }

graft.engine-split.design.md

Serving the feed from memory is what makes the Rust engine’s notifications cheap: a subscriber that stays close to the head reads each new commit straight from the ring, with no I/O at all, and the broadcast fans one append out to every listener. The ring is bounded on purpose — it holds only the most recent commits, so memory use is fixed no matter how long the engine runs. The cost of that bound is that a slow or briefly-disconnected subscriber can fall behind the oldest entry still in memory. The feed handles this without dropping anyone: because every commit is also a durable segment in object storage (Module 6, Module 9), a lagging subscriber simply reads the missing range from segments, catches up to the window edge, and resumes reading from the ring. So the feed is fast in the common case and complete in the worst case — the in-memory path and the durable path are the same ordered stream, just two ways to reach it. In the Rust engine this ring is the InMemoryFeed, and publish_feed_advance fires only when the remote LSN advances — a no-op push notifies no one — while eg.4 republishes those advances onto the EchoMQ lane egraft:feed:{vol} through a BusFeed sink, so a BEAM consumer observes them over the bus without the engine being touched. That durable floor — the shared remote both engines lean on — is the whole of Module 9.

§3

References & sources