B4.2 · dive 2 — the broadcast lane

One PUBLISH hop, and the loss stated as a gate.

A coherence write publishes on the table's channel; every node's table holds a RESP3 subscription and applies pushes in its owner. The substrate's contract is stated by its own documentation — Valkey pub/sub is at-most-once, "a message will be delivered once if at all" — so the lane is fast and lossy by construction. The rung derives the band first, measures inside it — median push latency 72 us over 100 messages, inside the derived band — and then states the loss as a gate of its own.

Source: content/bcs4.2.md, quoting bcs_rung_4_2_check.out; the push path is committed in the grown lib/echo_mq/connector.ex. This dive reads the broadcast derive line and gates F3 and F4.

The cross-node round trip, stepped. The F3 drill over two nodes and the shared L2 — the writer's put, the PUBLISH hop, the drops, and the read that falls through. Step through; the readout names each move and quotes the record where it lands.

readout · Press step to walk the F3 drill — the writer's put, the PUBLISH hop, the subscribers' drops, and the other node's read answering fresh from the shared L2.

Static walk — 1) the writer puts px=106.00 with its mint-time version: L2 first, so the truth is already shared · 2) one PUBLISH on ecc:{quotes}:coh — twenty-nine bytes · 3) the push frame reaches every subscribed table; each owner runs one comparison and drops its older row · 4) the other node's next read falls through its dropped L1 to the shared L2 and answers fresh.

§1

The transcript

bcs_rung_4_2_check.out · verbatim · this dive reads the derive line, F3, and F4

content/echo_data/runtimes/elixir/bcs_rung_4_2_check.out · verbatim · the broadcast half; the record opens with F1–F2 and continues through F6 — the hub holds it wholefrozen

… (F1–F2 elided; the full record is frozen on the module hub)
derive (broadcast): the lane is one PUBLISH hop on the wire whose committed sequential floor is 29,456 round trips per second, near 34 us each -- expect a median push latency between 30 and 500 us, and the receiver's apply is one ETS comparison on top
F3 broadcast ok -- median push latency 72 us over 100 messages, inside the derived band; the cross-node round trip holds -- the writer put px=106.00, 3 subscribers heard the name, and the other node's next read fell through its dropped L1 to the shared L2 and answered fresh
F4 loss ok -- the price of fire-and-forget, stated as a gate: :qc declared the job lane and holds no subscription, so the broadcast passed it by and it still serves px=100.00 -- bounded staleness until its own lane delivers, which is the next gate's business
… (the job-lane derive, the staged kill, F5, and F6 elided)
PASS 6/6

§2

The cross-node round trip

content/bcs4.2.md · What

The derive line is the chapter's evidence ethic in one move: the lane is one PUBLISH hop on a wire whose committed sequential floor is 29,456 round trips per second, near 34 us each, so the band is 30 to 500 us — and the measurement landed at median push latency 72 us over 100 messages, inside the derived band, with the receiver's apply one ETS comparison on top. The round trip the gate closes runs writer to reader across nodes: the writer put px=106.00, the push crossed the wire to three subscribed tables, and the other node's next read fell through its dropped L1 to the shared L2 and answered fresh.

The receiver never refetches on the push itself: an invalidation drops the L1 row, and the next read pays the normal cache-aside path against an L2 the writer already updated. Coherence drops; it never writes — a message means the writer already placed the newer value in L2, and the receiver's only move is to discard its older L1 copy. A receiver that wrote values carried by rumor would make every subscriber a writer, and the lane carries names, not rows.

§3

The loss, gated

content/bcs4.2.md · What · Boundaries

Fire-and-forget is a price, and the record pays it in the open: a table that declared the job lane holds no subscription, so the broadcast passed it by and it still serves px=100.00 -- bounded staleness until its own lane delivers. A missed broadcast costs one TTL of staleness — exactly the 4.1 bound — which is why the broadcast lane is declared per surface rather than assumed.

One broadcast, two declarations. Two fixed tables from the drill — :quotes declared the broadcast lane and holds a subscription; :qc declared the job lane and holds none. Deliver the same push to each and read what its declaration buys.

readout · Choose a table. The same twenty-nine bytes leave the writer either way; what happens next follows from one field in the table's declaration — its lane.

Static result — :quotes holds a subscription: the push arrives, the owner runs one comparison, the older L1 row drops, the next read answers fresh from the shared L2. :qc holds no subscription: the broadcast passes it by and it still serves px=100.00 — bounded staleness until its own lane delivers, which is the next dive's business.

The boundary is inherited whole: at-most-once, unpersisted, lost on disconnect — a node that reconnects has missed what it missed, the TTL bounds the damage, and resubscription rides supervision (the table restarts, the subscription returns; auto-resubscribe inside the connector is a carried knob, not a shipped feature). Declare :broadcast when staleness is tolerable but a tighter bound is cheap value — the lane costs one subscription per table per node and 72 microseconds per message. Declare :none when the TTL already says everything true. When at-least-once is a requirement, the next dive's lane carries the same twenty-nine bytes with a guarantee — the priced pair on the record's last row: broadcast median 72 us fire-and-forget, job lane median 148 us at-least-once -- the guarantee costs 2.1 times the latency.

§4

References

sources · related

Sources

Valkey — Pub/Subthe lane's contract taken whole: at-most-once, unpersisted, "a message will be delivered once if at all"
Valkey — Client-side cachingthe comparison set's invalidation messages: deletion-shaped, no version, no order
Lamport — Time, Clocks, and the Ordering of Eventsthe order that makes a dropped-row protocol safe

B4.2 — Coherence by Mint Timethe module hub; the full rung in context
B4 — EchoStorethe chapter landing; Part IV's arc
B3 — The Busthe wire the push frames share
B2.2 — Property Stores on ETSthe owner the applies run in
EchoMQ — the coursethe protocol in rung-level depth
Redis Patterns Appliedthe pub/sub substrate
Functional Programming in Elixirthe umbrella the runtimes live in