R0.3 · Overview — module hub
Patterns become protocol.
A handful of Redis patterns, owned the right way, stop being one library’s habits and become a protocol the bus itself declares: a closed key grammar, a three-field job hash, four sorted sets, eight verbs over six scripts — versioned, fenced, and backed by Valkey.
Grounding: content/bcs3.1.md · bcs3.2.md · bcs3.3.md · bcsA.md · docs/echo_mq/emq.design.md — every figure verbatim from a committed record.
Static verdicts — L4 runtime API → varies per runtime · L3 connector
→ varies per runtime, gated PASS 8/8 · L2 bundle → owned, versioned behind
the fence · L1 grammar → owned, versioned behind the fence · L0 Valkey →
external, an enforced conformance gate.
From patterns to an owned protocol
emq.md · bcs3.1–3.3A protocol here is not a network wire format. It is a declared Redis data convention
joined to a set of atomic Lua scripts — a written agreement about which key holds
which structure, what the row’s fields are, and which script makes each state change. EchoMQ owns
that agreement outright. The grammar is closed: every per-queue key parses as
emq:{q}:<type>, the job position is gated to branded ids, and the braced
{emq}: reserve holds the deployment’s own facts.
The job row is a hash of exactly three fields — state, attempts,
payload — and deliberately nothing more: no enqueued_at, because mint time
already lives inside the id. Four sorted sets carry the lifecycle — pending
(score-zero), active (lease-scored), schedule (run-at-scored),
dead — and eight verbs over six scripts move work between them. R0.2
fixed where Redis sits in the BCS build; this module answers why the worked examples
hold for any runtime that connects: the patterns are not language code. They are the bus’s owned
protocol.
The boundary is a fence, not a pin
bcs3.1 F3 · bcsA · verbatimThe boundary between L2 and L3 is the line between the owned protocol and the runtime’s own
code. What holds the line is not a pinned commit. It is the version fence: at every connect
— first boot and every reconnect — the connector reads {emq}:version, claims it
on a fresh keyspace, and refuses any other value with a typed error. The committed line reads:
GET {emq}:version answers echomq:2.0.0 through the fenced connector itself.
L4 runtime API — varies per runtime: EchoMQ.Jobs in Elixir; a Go loop around the same calls
L3 the connector — varies per runtime: RESP, pipelining, EVALSHA-first dispatch
——— the boundary — held by the version fence: a mismatch is a typed boot refusal ———
L2 the bundle # six Lua scripts, eight verbs; every key declared or root-derived
L1 the grammar # emq:{q}:<type> · the three-field hash · the four sorted sets
L0 Valkey # the engine — external, and an enforced conformance gate
Gated against live Valkey
The fence, the declared-keys dispatch, and the pipeline discipline are not aspirations — the connector’s gate record is committed, figure by figure.
fence claimed echomq:2.0.0 ← typed, fatal on mismatch pipelined EVALSHA 161192 ops/s ← declared-keys law at speed script_loads 1 ← exactly one NOSCRIPT load gate record PASS 8/8
The three dives
the layers → the owned core → the doorEach dive takes one part of the story. Read them in order — the four layers start.
The four layers
L0 Valkey to L4 runtime API; the claim script quoted verbatim; why the script is the contract — same bytes, same SHA1, same semantics.
The immutable core
The closed grammar, the four-member reserve, the three-field hash, the four sets — and the fence, the change rules, and the wire classes that hold the core still.
The door to EchoMQ
The contract retold — the script is the contract, the branded id is the wire form, one queue answers one slot — and the live doors to /echomq and /bcs.
Take the patterns a queue needs — atomic moves, leases, schedules, a morgue — write them down as a grammar plus scripts, version the result, and fence the boot.
The closed emq:{q}:<type> grammar, the three-field hash, the four sorted sets,
eight verbs over six scripts — owned, versioned, and backed by Valkey.
No upstream pin holds this protocol together. A closed grammar, a versioned bundle, and a two-way fence do — and after R0.3 the Overview chapter is complete and the pattern chapters begin.
References
sources · relatedSources
- Valkey — Topics — the engine the connector is gated against.
- Valkey — Programmability — atomic script execution, the basis of every transition in the bundle.
- Redis — Documentation — the command and data-type reference behind the catalog.
- llmstxt.org — The llms.txt convention — the machine-readable map format the course follows.
Related in this course
- R0.3.1 · The four layersthe stack, L0 to L4
- R0.3.2 · The immutable corethe owned core and its governance
- R0.3.3 · The door to EchoMQthe contract, and the doors
- R0.2 · Valkey under the Exchange Platformwhere Valkey sits
- R0 · Overviewthe chapter
- /echomqthe protocol in depth, rung by rung