R0.2.3 · Valkey under codemojex — dive 3

The reserved tier.

The tier this module once placed in reserve is no longer a reservation. EchoMQ is shipped, owned-protocol code: echo/apps/echo_mq, the Valkey-native bus — born braced, born branded, born declared.

Grounding: docs/echo_mq/emq.roadmap.md (the program) · emq.design.md (the protocol canon) · content/bcs3.3.md (the claim script) · bcs3.1.md + bcsA.md (the slot figures) — every figure verbatim from a committed record.

The tier as it stands. Select a part to read its role in the program — the bus, the named consumer, the engine.

readout · Select a part. EchoMQ at echo/apps/echo_mq is the bus; codemojex drains it; Valkey is the engine.

Static verdicts — the bus → echo/apps/echo_mq (EchoMQ.*, lib-only) · the consumer → codemojex (echo/apps/codemojex/) · the engine → Valkey, the only engine named.

§1

The tier, built

emq.roadmap.md

The earlier life of this page held a seat open: a multi-runtime layer the platform reserved for a bus to grow into. The program has since filled the seat with code. echo/apps/echo_mq is the bus — EchoMQ.*, lib-only — re-derived from first principles by the Branded Component System and shipped as measured, rung-gated code: born braced (emq:{q}:), born branded (JOB ids gated at the key builder), born declared (every Lua key declared or grammar-derived).

Two disciplines on that wire are birth conditions, not retrofits: operand keys are never built from an ARGV prefix inside a script body, and the keyspace has a total parse — every key declared or grammar-derived. A key a script touches but never declares is invisible to the gate, so the bus refuses it at the key builder, before anything reaches Valkey.

The tier also has a named tenant now. codemojex (echo/apps/codemojex/) is the program’s named consumer: command dispatch (Codemojex.CommandWorker), scoring (Codemojex.ScoreWorker), round settlement (Codemojex.Settle), and notifications (Codemojex.NotificationWorker) as EchoMQ.Jobs work drained by EchoMQ.Consumer and shaped by EchoMQ.Lanes.

§2

One atomic move, the real one

content/bcs3.3.md

The defining move of the bus is claiming the next job to work, and the script is committed — quoted verbatim:

content/bcs3.3.md · claim, the token mint · verbatimfrozen

local popped = redis.call('ZPOPMIN', KEYS[1])
if #popped == 0 then return {} end
local id = popped[1]
local jk = ARGV[1] .. id
local att = redis.call('HINCRBY', jk, 'attempts', 1)
redis.call('HSET', jk, 'state', 'active')
local t = redis.call('TIME')
local now = t[1] * 1000 + math.floor(t[2] / 1000)
redis.call('ZADD', KEYS[2], now + tonumber(ARGV[2]), id)
return {id, redis.call('HGET', jk, 'payload'), att}

One script, one claim: ZPOPMIN pops the lex-oldest pending id — score-zero means lex order is mint order — HINCRBY increments attempts, HSET marks the row active, and TIME stamps a lease on the server’s clock into the lease-scored active set. Atomic execution means the pop, the increment, and the lease land together or not at all. The quiet center is one integer doing two jobs: the attempts counter, incremented inside the claim, is the fencing token every other transition verifies — a right token retires the row; a stale token answers EMQSTALE.

The claim, stepped. Run the moves over a three-job queue; hover a structure to read its part. The lease figure is the committed 40 ms from the bcs3.3 crash drill.

readout · Run claim: ZPOPMIN pops the lex-oldest id, HINCRBY mints the token, the lease lands at t+40 ms on the server’s clock — one atomic step.

Static verdicts — claim → ZPOPMIN the lex-oldest, HINCRBY attempts to 1, lease at TIME+40 ms · complete with the right token → retires the row, nothing remains · complete with token 99 → EMQSTALE, the row survives · the committed round trip reads one job, two lives, one counter.

Notes on ValkeyThe clock inside the script is the server’s: TIME reads a frozen value for the script’s duration, and scripts replicate by effects — which is what makes a server-clock lease inside a write script sound, immune to client skew — valkey.io/topics/replication.

content/bcs3.3.md · the fence, performing · committed linesfrozen

complete with the right token retires the row -- nothing remains
EMQSTALE; the lease holder's work survives the zombie's complete
one job, two lives, one counter

§3

One queue, one slot, by grammar

content/bcs3.1.md F5 · bcsA

The claim script touches two keys — the pending set and the active set — plus the job row built from a declared prefix. What makes that multi-key move legal forever is the grammar: the hashtag is the queue name, so every key of one queue answers one cluster slot. The connector gate holds the same arithmetic client-side — slot 105 == 105 against 8507 for the payments queue, with the CRC16 specification vector answering 12739 (bcsA). Per-queue transition scripts are single-slot legal on the clustered day by grammar, not by review.

content/bcs3.1.md · F5, the co-location law · verbatimfrozen

pending, active, meta, and the job row of {orders} all answer slot 105; {fills} answers 4165

§4

The protocol is the contract

bcs3.2 · bcs3.3 · emq.roadmap.md

The reason one bus serves more than one runtime is not a port. It is that the protocol is the contract: the closed emq:{q}:<type> grammar plus the atomic Lua bundle. The same source string yields the same SHA1, and any client on any runtime that loads it speaks identical semantics — the same pop, the same token mint, the same lease arithmetic. A Go consumer is a loop around the same EVALSHA calls the Elixir reference makes (bcs3.3); the program roadmap names a Go sibling in its cross-runtime fleet, and a Node runtime is strictly proposed — not asserted.

the pattern

Reserve a seam for the bus, then fill it with a contract rather than a codebase: a closed grammar and a script bundle any conforming runtime can load.

its EchoMQ application

EchoMQ at echo/apps/echo_mq over Valkey — the bus the program extends rung by rung, with codemojex draining it.

The tier stopped being a reservation the day the bus shipped as owned code: one grammar, one bundle, one fence — extended rung by rung as the program grows.

§5

The doors

live routes · living status

This closes R0.2. The depth on the far side is taught by two courses — both doors are live routes.

/echomq

EchoMQ — the protocol, in depth

The program builds the extension ladder rung by rung: emq.0 lands the BCS migration; emq.1 (specced) is the scheduler + retry vocabulary; the families beyond — migration path, parent/flow, groups, batches, lifecycle, the cache deepened, conformance — are planned.

/bcs

The Branded Component System

The architecture the bus shipped inside — every figure from a frozen transcript.

…/overview/patterns-become-protocol

R0.3 — Patterns become protocol

The next module: why the worked examples hold for any runtime that connects — the protocol, owned.

§6

References

sources · related

Sources

Redis — ZPOPMIN — the pop that claims the lex-oldest pending id.
Redis — HINCRBY — the increment that mints the attempts fencing token.
Valkey — Replication — the frozen-TIME rule and effects replication behind the server-clock lease.
Valkey — Programmability — atomic script execution: the pop, the increment, and the lease land together or not at all.
Valkey — Cluster specification — hash slots, CRC16 modulo 16384, and hash tags as the same-slot mechanism.

Related in this course

R0.2 · Valkey under codemojexthe module hub — the pager loops back here
R0.2.2 · The two rolesthe previous dive; the bus role
R0.3 · Patterns become protocolthe next module; the contract for any runtime
/echomqthe protocol in depth, rung by rung
/bcsthe architecture, with the frozen transcripts