R0.2 · Overview — module hub
Valkey under the codemojex.
Before the patterns, the play. codemojex reaches one boundary —
the echo data layer — and below it Valkey serves two roles: EchoStore, the near-cache, an L1 of
ETS tables over the L2 Valkey, and the EchoMQ bus, the owned-protocol bus at
echo/apps/echo_mq — both over one Valkey, and no surface holds a raw Valkey key.
Grounding: echo/apps/echo_wire · echo/apps/echo_mq · echo/apps/echo_store ·
content/bcs3.1.md · bcs4.md · echo/apps/codemojex — every figure verbatim from a committed record.
The codemojex consumer is echo/apps/codemojex.
Static verdicts — the surfaces → call only the echo data layer, hold no raw key · the boundary → the single owned client (EchoWire) · EchoStore → derived, safe to drop · the EchoMQ bus → authoritative, the four sorted sets · Valkey → external, an enforced conformance gate.
Below the facade
bcs4 · emq.roadmap.mdThe codemojex reaches Valkey through one owned boundary — the echo data layer — and
every surface, from the play API to a background consumer, calls that boundary and reads typed results,
never a raw store condition. None of them opens a socket, holds a key, or branches on a wire error. The one
owned Valkey client is EchoWire (echo/apps/echo_wire); above it sit two
roles, both over Valkey: EchoStore, the near-cache in front of the read path — its
one-line case is the Part IV title made plain, branded keys, local speed, bus-driven
coherence — and the EchoMQ bus, the owned-protocol bus at
echo/apps/echo_mq: the closed braced emq:{q}:<type> grammar, the
three-field job hash, the four sorted sets, eight verbs over six scripts.
That single rule is the master invariant the whole course respects. It is why a cache can be added, swapped, or deleted without a surface changing — and why the bus could be re-derived and shipped as new code, the program story the third dive retells, without a surface changing either. The diagram above shows the boundary; the first dive proves it.
Two roles, one store
content/bcs3.1.md · bcs3.2 · bcs4Below the facade the store does two distinct jobs, and the two roles ground different halves of the
catalog. The cache machine is EchoStore. It holds derived state —
a copy of the truth, safe to drop; a dropped row costs a slower read, never a lost fact. The caching and
data-modeling families ground here. The EchoMQ bus holds authoritative state — the
jobs are the work. Per queue, four sorted sets carry the lifecycle: pending
(score-zero, lex order is mint order), active (lease-scored), schedule
(run-at-scored), dead. The queues, coordination, streams, and flow-control families ground
here. The second dive opens both roles with their committed figures.
The keyspace under both roles
On Valkey, the braced hashtag is what keeps every key of one queue in one cluster slot — co-location by grammar, not by review. The bus’s committed keyspace line names every shape at once.
emq:{orders}:pending | emq:{orders}:job:ORD0NgWEfAEJfs | {emq}:version | {emq}:locks -- 17 bytes before the payload
Notes on ValkeyIn a sorted set, elements with the same score are
ordered lexicographically — which is why the score-zero pending set browses in mint order
with no second index —
valkey.io/topics/sorted-sets.
The three dives
the seam → the roles → the tierEach dive takes one part of the play. Read them in order — the facade seam starts.
The facade seam
The master invariant: every surface calls only the echo data layer and reads typed results, never a raw key. EchoWire is the one owned Valkey client below it.
The two roles
EchoStore, the derived near-cache in front of the read path, and the EchoMQ bus, the authoritative state below — and which pattern families ground in each half of the catalog.
The reserved tier
The tier once held in reserve, now shipped: EchoMQ at echo/apps/echo_mq, the
Valkey-native bus, with the real claim script as the worked
move.
Keep one store below one facade, in two clear roles. Surfaces never depend on the store, and the store can change without them.
EchoStore and the EchoMQ bus over one owned client, EchoWire, both on Valkey — the
near-cache derived, the bus authoritative, and the bus’s protocol owned outright.
Three dives, one play: the seam that holds, the two roles below it, and the tier that stopped being a reservation and became shipped code. After R0.2, the next module — R0.3 · Patterns become protocol — shows how the bus’s patterns become a protocol any conforming runtime speaks.
References
sources · relatedSources
- Valkey — Sorted sets — equal-score lexicographic ordering, the fact behind the score-zero pending set.
- Valkey — Cluster specification — hash tags as the same-slot mechanism behind the braced keyspace.
- 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.2.1 · The facade seamthe master invariant
- R0.2.2 · The two rolesthe near-cache and the bus
- R0.2.3 · The reserved tierthe tier, shipped
- R0 · Overviewthe chapter
- R0.3 · Patterns become protocolthe next module
- Functional Programming in Elixirthe functional-Elixir and OTP craft behind the umbrella