The Protocol · module 03
What holds the
wire together
The keys are fixed for a wire, the ids are branded, and an executor that does not match the node's wire is refused.
The keyspace says where, the record says what, the transitions say how
— each one atomic server-side step, run by the scripted executor (the inline Lua, EVALSHA-first)
or the native module (one EMQ.* command per core job transition). This module
teaches what keeps all of it honest over time. Three guards do it, on both executors: the
immutable line — the keys, the field names and the transition contracts are fixed for a wire,
and a change to any of them is a new wire with a new identity; the branded-id gate — a job id is
a 14-byte branded Snowflake under JOB, all fourteen bytes checked by the host, the
three-byte namespace checked inside the transition before a row is written; and the version
fence — the reserved {emq}:version key the connector claims or verifies at
connect on its default wire 4 and only reads on wire 6, and the native module's write verbs verify on every write
and never write. Beside it sits the
module fence: EMQ.VERSION and TRA.CAPABILITIES
report what the loaded module is and serves. All real code, grounded in
echo/apps/echo_mq, echo/apps/echo_wire and
trafikist/crates/trafikey.
The three guards
Three things hold the wire together, and the three dives of this module are each one of them. Each guard is held on both executors — the scripts and the native module — by real code on each side. Pick a guard and an executor to read what holds it there and the surface that carries it, then take the dive.
What holds the wire · pick a guard and an executor
the inline Lua writes the fixed fields state, attempts, payload at the fixed keys emq:{q}:<type>, under the identity
echomq:4.0.0.surface: EchoMQ.Keyspace.queue_key/2 + the @enqueue field write
a rename made in one speaker desyncs it from every other, and the fence passes it; a change made as a new wire carries a new identity.
Three guards, one wire, two executors: the line keeps the substrate from shifting under either one, the gate keeps a stranger's id out of both, and the fence keeps each executor off a node that holds the other's wire.
The dives
Three dives, each one guard. Each grounds in real code on both sides of the executor line — the keyspace
builder and the @enqueue gate in echo/apps/echo_mq, the
connector's fence in echo/apps/echo_wire, and the native handlers and fence in
trafikist/crates/trafikey.
The immutable line
Why the keys, fields and transitions are fixed for a wire; change one thing and read who can still find the row.
The branded-id gate
The 14-byte branded id the host checks, and the 3-byte EMQKIND gate both executors run.
The version fence
The {emq}:version key: claimed or verified at connect by the scripts, verified on every write by the native module.
Redis Patterns Applied
This is the depth behind R2 · Coordination in
Redis Patterns Applied: the branded-key and atomic check-then-act patterns —
atomic updates and the
one-slot move — are exactly what the
@enqueue gate and the SET … NX fence apply. There the pattern
is the door; here is the wire it guards.
Up next
The next module is The native module: the core job transitions compiled into the server, where the second fence lives. The chapter then closes in the workshop; or step back to the chapter to take the keyspace, the record, and the Lua layer in any order.
The native module
The core job transitions compiled into the server: one EMQ.* command each, a read-only fence on every write.
Workshop
Decode a real key, then trace one transition through its executor.
Back to The Protocol
The chapter: the keyspace, the record, the Lua layer, immutability, the native module.
References
Sources
- Valkey — Documentation — the store the keys, the record, and the scripts run inside — the substrate of record.
- Valkey — SET — the
NXatomic claim the scripted fence uses. - Valkey — Modules Introduction — how a module adds commands to the server; the native module is one.
- Redis — EVALSHA — the load-once, run-by-SHA dispatch the scripted gate rides on.
- llmstxt.org — The llms.txt convention — the machine-readable map format the course follows.
Related in this course
- The Protocol — the chapter this module belongs to.
- The protocol below the line — the line, on a real key and script.
- redis-patterns R2 · Coordination — branded-key and atomicity, the near side of the door.