The door & the BCS family

EchoMQ does not stand alone. It is where every Redis pattern lands, and the wire underneath the systems built on it.

The course next door — Redis Patterns Applied — teaches each Redis pattern, proves it with one excerpt, then doors here for the system that runs the pattern in depth. This course is the far side of all of them. And EchoMQ is the bus of the Branded Component System: own the Queue, the Bus, and the Cache once, and every system built on BCS inherits all three. Pick a pattern on the right to follow its door to a pillar.

The bidirectional door What the family inherits How to read the course References

Follow a door · pick a Redis pattern

Caching —> the Cache. cache-aside, write-through and stampede control land on the real L1/L2 near-cache.

The bidirectional door

Two courses teach EchoMQ's world from two sides. Redis Patterns Applied teaches each Redis pattern applied — cache-aside, reliable queues, streams — and proves it with one real excerpt. Then it doors here, where the same pattern is run in depth by a real pillar. A door is a teaching hand-off, not a grounding claim: a chapter can ground its excerpt in one system yet door here for the system that applies the pattern.

The link is governed by one canonical table — the edge map both courses read. It is bidirectional: every forward door has a matching reverse-link, and where a page and the map disagree, the map wins. Each door points at the named pillar route it belongs to.

Redis pattern	Doors into	Why
Caching	the Cache	cache-aside, write-through, stampede control → the real L1/L2 near-cache
Coordination	the Protocol	atomic updates and locks → the atomic transitions: Lua scripts, and native commands for the core job transitions
Reliable queues	the Queue	the wait → active → done → recover lifecycle → the worker loop
Time, delay & priority	the Queue	delay, promote, backoff-retry, intra-group priority → lifecycle + lanes
Streams & events	the Bus	event fan-out and a replayable log → pub/sub and the event log
Flow control & scale	the Queue	rate-limiting, fair lanes, batches → lanes + batches
Data modeling & memory	the Protocol	the job hash and its compressed fields → the owned data layer
Production & operations	the Proof	operating the tier at scale → the conformance suite and telemetry

The two courses already speak to each other: the near side of the door is Patterns become protocol, and every Redis Patterns chapter opens onto a pillar taught here — Caching, Coordination, Reliable queues, Time, delay & priority, Streams & events, Flow control & scale, Data modeling & memory, and Production & operations.

A pattern is transferable knowledge; a pillar is the system that runs it at depth. The door carries the reader from one to the other — in both directions.

What the BCS family inherits

EchoMQ is the bus of the Branded Component System. A BCS system is a set of components that talk only through branded identity over one owned wire — and EchoMQ is that wire. So building a system on BCS does not start from an empty page: the three pillars are already there. Pick a pillar to read what a system gets the moment it is built on the wire.

What the family inherits · pick a pillar

the Queue (distribute work) — surface: EchoMQ.Jobs.enqueue/4 + EchoMQ.Consumer (lease default 30_000 ms). A BCS system gets it for free: one job, one worker, held by one atomic transition on the server (the Elixir verbs send it as a Lua script); fair lanes (EchoMQ.Lanes) and the full lifecycle, not bolted on.

# A system built on the wire calls all three pillars directly.
# Nothing else sits between its components: the wire is enough.

# the Queue — distribute work (one job, one worker, one atomic transition)
  EchoMQ.Jobs.enqueue(conn, queue, job_id, payload)   # a producer hands off work
  EchoMQ.Consumer # claims with a lease (default 30_000 ms), runs it, completes it

# the Bus — broadcast signals (pub/sub on emq:{queue}:events)
  EchoMQ.Events.subscribe(server)            # a component listens
  EchoMQ.Events.publish(conn, queue, event, job_id)  # another broadcasts

# the Cache — serve reads (single-flight, coherent by mint time)
  EchoStore.Table.fetch(name, id)              # a hot read does not become a hot key

the idea (the pattern)

Redis Patterns Applied teaches transferable patterns — cache-aside, reliable queues, streams — and proves each with one excerpt, then doors forward.

the implementation (EchoMQ)

Each door lands on the pillar that runs the pattern in depth, over one owned wire — the same Queue, Bus, and Cache every BCS system inherits.

A door is one-way teaching; a wire is two-way infrastructure. Redis Patterns Applied hands its patterns to this course; this course hands the Queue, the Bus, and the Cache to every system built on the Branded Component System.

How to read the course

The six chapters fall into three arcs. Read the foundation, then take the pillar you need, then see the proof that the whole system holds.

1 · the foundation: The Overview (this chapter) frames the system; The Protocol teaches the substrate all three pillars share — the owned emq:{q}: keyspace, the record hash, the atomic transitions on both executors (the Lua layer and the native module), immutability and branded ids.
2 · the three pillars: The Queue distributes work; the Bus broadcasts signals and keeps the event log; the Cache serves reads. Read the Protocol first, then take the pillar you need.
3 · the proof: The Proof chapter shows the system holds — the conformance suite, and telemetry with its read plane.

The pillars stand side by side: after the Protocol, take them in any order.

Recap — where EchoMQ lands

EchoMQ sits at the centre of a small web. On one side, the door from Redis Patterns Applied: every pattern — caching, reliable queues, streams — lands on the pillar that runs it in depth, and the link is bidirectional. On the other side, the BCS family: own the Queue, the Bus, and the Cache once, and every system built on the Branded Component System inherits all three over one wire. Read the course as foundation, then pillars, then proof. The chapter loop closes back at the Overview landing.

Next: back to the Overview landing — the three-pillar map and the route into the depth chapters.

References

Where the wire, its engine, and the courses on either side of the door are grounded.

Sources

Valkey — Documentation — the BSD-licensed, foundation-governed store EchoMQ is backed by — the substrate of record.
Redis — EVALSHA — the load-once, run-by-SHA dispatch the scripted executor runs its scripts with, the same in every runtime.
Valkey — Cluster specification — the {hashtag}→hash-slot routing the per-queue-hashtag keyspace is built for: every key of a queue on one slot, where a multi-key script is legal.
llmstxt.org — The llms.txt convention — the machine-readable map format the course follows.

Related in this course

The three pillars — what EchoMQ is (the first dive).
The protocol below the line — why the pillars interoperate (the previous dive).
The Protocol — the substrate all three pillars share.
Redis Patterns Applied — the course that doors here, pattern by pattern.
redis-patterns · Patterns become protocol — the near side of the door.
The Branded Component System — the architecture EchoMQ is the bus of.
Course home — the full six-chapter map.