jonnify·persistence /echo-persistence/platform/the-door-to-bcs/codemoji-on-the-substrate

Module 15 · Dive 14.3 · the finale

Codemoji on the substrate.

To see the door is one thing; to see something standing on the other side is another. Codemoji’s Broadcast system is a BCS system end to end: four branded entities, components as data, the audience held by reference. And it cashes in the course’s oldest idea at the last moment — the BDV delivery id is the chronological key, so the hour-long fan-out of a broadcast compacts to a single result by folding in mint order, with no sort. Run a broadcast and compact it below, and watch the whole course pay out.

Four entities, one fold. A template (BTP) holds a ref to its audience (RGP) and instantiates a run (BCA), which emits one delivery (BDV) per recipient. Because each BDV id is minted in order, the deliveries are already chronological — compaction folds them into a Result with no sort, and trims the transient rows.
BroadcastTemplate · BTP content + schedule + period recipient_group: RGP (ref) RecipientGroup · RGP owns the audience referenced by id, never embedded ref by id (the law) Broadcast · BCA a run · state machine emits BDV / recipient → Result (BTP/run) sent=0 · failed=0 fold in mint order · NO sort →
readout · a BTP references its audience by RGP id and instantiates a BCA run that emits one BDV per recipient. run broadcast, then compact to fold the deliveries in mint order.
§1

A BCS system, on the floor

notifications.design.md

Codemoji’s Broadcast system is the worked proof that the discipline is buildable, and it is BCS to the letter. It has four entities, each a branded identity: a BroadcastTemplate (BTP) — reusable content, schedule, and a compaction period; a Broadcast (BCA) — one run of a template, a state machine whose components aggregate as it goes; a BroadcastDelivery (BDV) — one per recipient message; and a RecipientGroup (RGP) — the audience and the failure sink. Their data are plain component bundles, never behaviour. The audience is held by reference: a BTP carries the RGP id, not an embedded recipient list — the law from the last dive, in production. And each entity is owned by a system-process gated on its namespace, so the only things crossing between them are identities and messages about identities. Every primitive it stands on is from the floor this course built: the deliveries are property rows keyed by their branded id (14.1), the run’s state stays coherent by newer-wins, the durable record is a Graft commit, and the sends ride the EchoMQ bus. Nothing here is bespoke infrastructure; it is the substrate, used.

§2

The substrate pays off — and the course closes

notifications.design.md · the snowflake property

The sharpest payoff is the one the very first modules set up. A broadcast to a large audience produces a great many transient BDV rows, and after the template’s period elapses they must collapse into a single durable Result. In most systems that is a sort-and-aggregate over a timestamp column. Here it is neither: because a BDV’s id is a branded snowflake, and a branded snowflake sorts lexicographically in mint order, the deliveries are already chronological — compaction reads them in mint order with no sort at all, folds them into the Result, and trims the transient rows. The same property that gave free-order stream archival in Chapter 11 and a version-free coherence rule in 14.1 here gives free-order compaction in an app. Step back and the whole course is one idea, applied at every layer: a branded id that sorts by birth becomes the loss-window dial of the accept tier, the LSN cursor of the commit tier, the recovery key across runtimes, the version for cache coherence, the chronological key for compaction, and finally the entity of a component system. The durable floor was always in service of this — a place where state keyed by a time-ordered identity is cheap, replicated, and coherent — so that systems built the BCS way get their hardest properties for free. That is the door this course opened. On the other side, the platform is just identities, components, and systems — standing on Echo Persistence.

Fin · Echo Persistence. Fourteen modules, four chapters: the durability spectrum and the Champ accept tier; the local CubDB store and MVCC; the Graft engines, the fence, and the cross-runtime contract; and the platform — the bus, its composition with the floor, why it beats classical scheduling, and the door to BCS. One branded id threaded all of it. Use the pager to return to the map, or begin again at Module 1.
§3

References & sources