Pub/Sub vs Streams — fire-and-forget, or remembered.

A Redis channel is a delivery, not a store. PUBLISH channel payload sends the payload to every connection currently subscribed to channel and returns the number of subscribers it reached. There is no buffer, no backlog, no cursor: a subscriber that connects one millisecond later sees nothing of what came before, and a publish that reaches a subscriber count of zero is a no-op the sender cannot distinguish from success. This is the at-most-once promise — a message reaches a present subscriber zero or one times, never stored for a late one.

A Stream inverts every one of those defaults. XADD key * field value appends an entry, assigns it a monotonic id, and keeps it in the log until a retention policy removes it. A reader reads with XRANGE or XREADGROUP from any position — the start, a saved cursor, or only-new — so a reader that was absent reads what it missed, and a reader that crashed resumes where it stopped. The log remembers; the channel does not. Neither is the better one: a live metrics tick wants the channel's no-storage simplicity, and an audit trail wants the log's durability. The error is using the channel where the promise needed was the log's.

EchoMQ.Events is EchoMQ's pub/sub surface, and it is honest about the promise. It subscribes once to the per-queue channel emq:{q}:events and dispatches each lifecycle event — a job completed, failed, scheduled, stalled — to the pids that registered with subscribe/2 and to an optional handler module, so a consumer reacts to work as it happens without polling the sets. The moduledoc states the cost in one sentence, and that honesty is the lesson.

The mitigation is not a buffer — adding one would make it a different channel. It is the emq.1 resubscribe: a connector that reconnects re-issues its SUBSCRIBE, so the feed comes back live across a drop, narrowing the loss window to the reconnect itself. And where a receipt is actually required — replay, audit, a reader that must not miss an entry — the answer is the durable channel, not a harder push: EchoMQ.Stream, not EchoMQ.Events.

EchoMQ.Stream.append(conn, queue, name, fields) is the other promise. It mints an EVT-branded record id host-side, appends XADD emq:{q}:stream:<name> <id> id <branded> <fields…>, and returns {:ok, branded} — the branded id is the receipt. Where a publish answers a subscriber count it cannot interpret, an append answers a durable handle the caller keeps. The entry stays in the log until retention removes it, readable by any reader at its own pace, replayable from the start.

The same event can travel both channels, and often should: append it to the Stream so the record exists and can be replayed, and publish a lighter notification on Events so a live dashboard reacts without reading the log. The Stream is the source of truth; the publish is the doorbell. What a publish forgets the instant no one is listening, the log still holds for the reader who arrives a minute later.

The decision is not taste; it follows from the promise each channel makes, and it reduces to one question: does a reader who was not present need to read this later? If yes — replay, resume after a crash, an audit trail, time-travel to a past window — the answer is the Stream, every time. If the value of the message is genuinely now-or-never — a live progress tick, a presence ping, an ephemeral control signal — Events is enough and cheaper.

The default is the Stream. The reasoning is asymmetric: a Stream can always feed a live reaction too — a reader tailing the log reacts within a round trip — but Events cannot become durable after the fact, since a message published with no subscriber is gone. Choosing the Stream keeps the durable option open and still serves the live case; choosing Events forecloses durability. EchoMQ made that choice for its own lifecycle: the system of record is the durable Stream, and Events exists for live reaction on top.

The fire-and-forget side carries one operational cost the publish side hides: a subscriber monopolizes its connection. The moment a connection issues SUBSCRIBE, it enters subscriber mode and can no longer run ordinary commands — a GET on that connection is refused until it unsubscribes. A subscriber is therefore not a connection borrowed from the shared pool; it is a connection given over to listening.

EchoMQ.Events takes that as a requirement, not an accident. Its :conn must be a RESP3 connector (protocol: 3) with push_to set to the listener process, so pushed messages arrive as {:emq_push, …} mailbox frames on a connection dedicated to the subscription — the same dedicated-lane discipline the blocking stream read follows. A verb that holds a connection gets its own connection, so the single-owner socket the rest of the system shares is never stalled. The third dive reads this seam in full.

The arc is see the two promises → learn the rule → pay the cost. Read them in order — the first sits the at-most-once publish against the durable receipt, the second turns the difference into a decision, and the third reads the one operational cost the fire-and-forget side carries.

codemojex (echo/apps/codemojex) is the worked consumer — a Telegram emoji-guessing game on the same stack. Its round lifecycle uses both channels for what each is good at. A round event — a round opened, a guess scored, a round settled — is appended to the durable activity Stream so the full history exists and a feed reader can replay it or resume after a restart. A lighter notification rides EchoMQ.Events so a live Telegram view reacts the instant something happens, without reading the log. If that publish reaches no live view, nothing is lost that matters: the Stream still holds the record. Durable where a record is needed, live where reaction is needed — one event, two channels, each making the promise it should.