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

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. As the pillars land, each door re-points to 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 Lua / EVALSHA substrate
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 → conformance, telemetry, benchmark

The two courses already speak to each other: the near side of the door is Patterns become protocol, and the four built Redis chapters — Caching, Coordination, Reliable queues, and Time, delay & priority — each open onto a pillar taught here.

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

# One worked consumer rides all three pillars: the Exchange Platform.
# It needs no other infrastructure between its components — the wire is enough.

# the Queue — distribute work (one job, one worker, atomic in Lua)
  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 for fills
  EchoMQ.Events.publish(conn, queue, event, job_id)  # another broadcasts them

# the Cache — serve reads (single-flight, coherent by mint time)
  EchoCache.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. The Exchange Platform proves a real system rides all three pillars and needs nothing between its components.

How to read the course

The six sections 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 Lua layer, 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, telemetry and tracing, the benchmark gate.

The Protocol is ready to read alongside this Overview; the three pillars and the Proof chapter are on the build front, each added as its pages land.

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, with the Exchange Platform the worked consumer. 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 wire runs its scripts with, the same in every runtime.
DragonflyDB — Server flags — the thread-per-shard engine the declared-key, per-queue-hashtag keyspace is built for.
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.
Functional Programming in Elixir — the language the course is canonical in.
Course home — the full six-section map.