echd — Echo on Encore · E3.4 · dive

The Topic, Re-landed

The topic name becomes a stream key, publish becomes XADD, and a subscription becomes a consumer group — run it on the Valkey at :6390 and replay the events a PubSub subscriber would have missed.

Vision · real substrate

echd speaks in the present tense over a build ladder. Every module, verb, key, and port named on this page is real; the composition into one standing platform is the vision the ladder builds.

§1

The dive

docs/echo_mq/emq.streams.md:29-42

Re-landing a topic is a rename and a promotion at once. The rename: an Encore topic called user.signup becomes a stream key, emq:{user.signup}:, and publishing an event to it is XADD. The promotion: a subscription, which in PubSub is a fleeting delivery, becomes a consumer group you read with XREADGROUP and complete with XACK. Nothing about the shape of the code that publishes changes; what changes is that the event is now written to a log that is kept.

Run it on the Valkey already listening on :6390 and the difference is something you can see, not take on faith. Publish three events. Start two consumers in a group and read: each event goes to exactly one of them, the group tracking who has which. Then read the stream again from id 0 — and the three events are still there to be re-read. That last step is the one PubSub cannot answer: a subscriber that was offline when a message was published has no way to ask for it later. The re-landed topic keeps its history, so it can.

§2

Publish, read, replay

docs/echo_mq/emq.streams.md:29-42

An Encore topic, re-landed on a stream and a group · hover to read

Publish is XADD. The topic's name becomes a stream key — emq:{user.signup}: — and publishing an event is XADD, which appends it in mint order. Nothing about the publisher changes conceptually; what changes is that the event is kept, not dropped the instant it is delivered.

Read is a group. A subscription is a consumer group. Start two consumers, read with XREADGROUP, and each event goes to exactly one of them; XACK marks it done. Two workers now share the topic's load, and the group remembers what each still owes.

Replay is there. Read the same stream with XREADGROUP from id 0 and the whole retained history comes back — the events are still on the log. A PubSub subscriber that was offline when they were published has no way to ask for them; the stream tier still has them.

Hover or focus a step to read it; click to pin. Without scripting, all three read in sequence.

§3

The mapping, line by line

docs/echo_mq/emq.streams.md:29-42

The re-landing is exact enough to write as a table you can keep beside a terminal. A topic t is the key emq:{t}:. topic.Publish(event) is XADD emq:{t}: * …. Creating a subscription is XGROUP CREATE, and consuming it is XREADGROUP GROUP g c > followed by XACK when the work is done. A consumer that dies mid-work is recovered by XAUTOCLAIM, and retention is set by XTRIM. Every Encore PubSub concept has a one-line Valkey equivalent, and none of them needs a broker in the middle.

What the table does not have is a row for "replay," because PubSub has no such concept to map from — and that is the point. Re-landing does not merely reproduce the topic; it upgrades it. The cost of the upgrade is the one at-least-once always charges: a consumer must be idempotent, because XAUTOCLAIM can redeliver work whose result never got acknowledged. Run the whole loop on :6390 — publish, read in a group, kill a consumer and watch its work reclaimed, then replay from 0 — and the supersession stops being a claim on a slide and becomes a session in a shell.

§4

The rule

one line to carry

The re-landing rule — a topic is a stream key and a subscription is a consumer group, so publishing is XADD and subscribing is XREADGROUP — and the log stays. The same event flow, now retained and replayable, at the cost that a consumer must be idempotent; run it on Valkey at :6390 and read yesterday's events back, which PubSub could never do.

§5