Module 13 · Chapter IV — The platform
EchoBus + Echo Persistence.
Eleven modules built two things that look separate: a message bus (EchoMQ) and a durable floor (the engines and store of EP1–10). This module is the claim that they are one system. They meet at exactly three seams — a shared cursor, an outbox, and a fold — and through those seams a write becomes a loop across four tiers: accepted, committed, published, and folded back. Tap each seam below to see what crosses it.
Why it is one system, not two
graft.design.mdIt is tempting to read the course as two stacks bolted together: a queue on one side, a database on the other. The platform’s design refuses that split, and the reason is the commit LSN. When the accept tier (Champ, in-memory with an fsync every K records) folds a batch into a Graft transaction, that batch becomes one LSN replicated to Tigris — and that same LSN is published over EchoMQ. A number that means “this much is durable” on the store side is the identical number that means “subscribe from here” on the bus side. So the two halves do not exchange data through an adapter that could drift; they share a cursor. That single fact is what makes a replica’s position, a consumer’s offset, and a commit’s durability the same coordinate, and it is why the rest of the module can talk about a loop rather than a pipeline: the engine’s commit drives the bus, and — through the archive fold — the bus drives the engine’s commit. Everything else in this module is a consequence of choosing one cursor for both worlds.
The three seams
graft.engine-split.design.md · emq3.5The coupling is not diffuse; it is exactly three seams, and each is a dive. The cursor (①) is the accept–commit join: the caller picks the guarantee per call — :async returns once the batch is fsync’d locally, :sync only after the Tigris-replicated commit acknowledges — and the published LSN binds every replica to the same point. The outbox (②) is the deliberate non-coupling of the hot path: the bus stays on Valkey because it must be fast, and durability stands beside it as a low-volume transactional-enqueue outbox (EchoStore.Durability), so a durable write never enters the enqueue path — its adapters are SQLite and Memory, with the Graft commit-log as a bring-your-own option. The fold (③) is the return leg: the Stream Tier’s retention does not delete history, it archives it — a dedicated fold consumer commits trimmed stream slices into the engine with EchoStore.Graft.commit/3, fold-before-trim, so the bus’s old tail becomes the store’s durable segments. Read the seams in order and the loop is complete: a write is accepted, committed (①), recorded beside the bus (②), carried as events, and folded back into the store (③).
The three dives
module 13The commit LSN is the cursor
The accept tier and the commit tier join at the batch; one batch is one LSN; :async vs :sync per call; and the published LSN binds every replica and consumer to the same point.
The outbox beside the bus
The dual-write trap, and why EchoMQ sidesteps it: the bus stays on Valkey while a low-volume outbox journals intents beside the hot path. The Adapter contract; SQLite/Memory.
The loop closes
The archive fold commits stream slices into the engine (EchoStore.Graft.commit/3, fold-before-trim) — the four tiers become a cycle joined by the cursor and the feed.
Up next
chapter IVReferences & sources
- Echo records
- graft.design.mdthe two-tier join; the commit LSN published over EchoMQ binds replicas; :async / :sync
- graft.engine-split.design.mdEchoStore.Durability — the outbox beside the bus; SQLite / Memory adapters
- emq.streams.mdemq3.5 — the archive fold into EchoStore.Graft
- store.design.mdEchoStore module architecture; dev↔prod durability knob
- External
- Transactional outboxthe dual-write problem the seam avoids
- Change data capturethe commit log as an event source