← the depth behind redis-patterns R5 · Streams & Events
The Bus · module 01
The events channel
Fan one signal out to everyone listening, now and gone — the bus's lightest surface.
The Queue hands one job to one worker. The events channel does the opposite: a
publisher fans a single signal out to everyone listening, on one channel per queue,
emq:{q}:events. Its job is to let a consumer react to work as it happens
— completed, failed, progress,
stalled — without polling the sets on a timer. Three moves carry the whole surface:
subscribe once, publish after the verdict, and fire-and-forget.
It is all real EchoMQ.Events code.
One publish, N deliveries
A publisher issues one PUBLISH emq:{q}:events; the channel fans the message out to
every live subscriber and the handler module. The events the bus carries are the lifecycle transitions —
each published host-side after its verdict (except progress, which the
@update_progress seam already publishes inline). Pick an event to read the cjson payload
it carries and where it is published from. The point the figure makes: one publish, N deliveries
— and zero if no one is listening.
The events fan-out · pick a lifecycle event
One wire, one publish — the channel fans it to whoever is listening at that instant, and to no one if no one is. The events say it once.
The two deliveries
A subscriber chooses how it wants the events, and both run off the same one subscription. There is no second
connection, no second SUBSCRIBE, and no extra wire cost per subscriber beyond a
send/2. Pick a delivery shape to see the call and what it receives.
Two deliveries, one subscription
Both deliveries happen on the listener's single emq:{q}:events subscription.
The subscriber-pid shape is loose coupling — a LiveView, a metrics collector, a test process, each
pattern-matching what it cares about. The handler shape is a stateful reducer — fold the event stream into a
running state.
The dives
Three dives, one per move, each grounded in the real echo/apps/echo_mq code — the
one-time subscribe and the two deliveries, the host-side publish after a verdict, and the at-most-once posture
with its cooperative-cancel sibling.
Subscribe and handle
Subscribe once to emq:{q}:events on a RESP3 connector; delivery two ways — subscriber pids and the handle_event/3 handler.
Publish after the verdict
publish/5 issues PUBLISH host-side after a transition decides; the gated id, the hand-built cjson, the substring-scan read.
Fire-and-forget
At-most-once: a publish with no live subscriber is lost; the resubscribe mitigation, the stream as the durable receipt, and EchoMQ.Cancel.
Redis Patterns Applied
This is the depth behind the Redis Patterns Applied chapter that doors here: R5 · Streams & Events — the publish/subscribe events that let a consumer react without polling are exactly what this module makes concrete on the real wire. There the pattern is the door; here is the implementation.
The durable receipt
The events channel is fast and lossy by design: it broadcasts the present and keeps nothing. When an event must
survive — replayed by a reader that was not running yet, audited, consumed at-least-once
— you do not harden the channel; you write to the stream log
(EchoMQ.Stream), an append-only, durable, replayable log. The event channel is the
reflex; the stream is the memory. The same branded id threads both — an event names a
JOB; a stream record IS an EVT. Where the log ultimately folds
to disk is Echo Persistence.
The rest of the pillar
The events channel is the bus's reflex. The stream log is its memory — the durable, replayable receipt this module keeps pointing at. The Protocol below the pillar — the keyspace these channels are born to — is ready to read now, and so is the Queue, the bus's mirror over the same wire.
The Bus
The pillar this module opens: events plus the durable, replayable stream log.
The Queue
Distribute work: one job, one worker — the mirror of the bus over the same wire.
The Protocol
The substrate: the braced keyspace the events channel and the stream keys are born to.
Streams & Events
The pattern side: pub/sub and the stream patterns this pillar realizes.
The Bus pillar, the Queue, and the Protocol are ready to read; the remaining Bus modules — the stream log, consumer groups, time-travel, retention & the archive — are on the build front, each added as its pages land.
References
Sources
- Valkey — Introduction to Streams — the bus surfaces this pillar builds on; the events channel is the pub/sub half.
- Valkey — PUBLISH — the single command the events channel issues to fan a message out to every subscriber.
- Valkey — SUBSCRIBE — the one-time subscription the listener holds on
emq:{q}:events. - Valkey — Cluster specification — the
{q}hashtag forces the events channel and the stream onto one of 16384 slots, co-located with the queue.
Related in this course
- Subscribe and handle — the one-time subscribe and the two deliveries.
- Publish after the verdict — the host-side publish and the substring-scan read.
- Fire-and-forget — at-most-once, and the cancel control signal.
- The Bus — the pillar this module opens.
- The Queue — distribute work; the mirror of the bus over the same wire.