← the depth behind redis-patterns R8 · Production Operations
The Proof · module 02
How it reports
on itself
Push the events as work happens; pull the state whenever you ask — and never change the work either way.
A proven system still owes you one answer: how is it doing right now — and it
has to answer without being asked to change. The bus answers two ways, mirror images of each other.
Push (EchoMQ.Meter): as work happens the lifecycle emits
[:emq, …] events the standard Elixir :telemetry way — attach
a handler and throughput, latency, and failures flow to it, at zero cost when telemetry is absent.
Pull (EchoMQ.Metrics): a pure-read plane answers counts,
a job's state, throughput, and the rate-gate off the as-built structures — every verb observes, none
mutates. One side observes by emitting; the other answers by reading. It is all real code.
Push and pull, one lifecycle
Both reports watch the same thing — a job moving through its lifecycle — from opposite sides. The meter sits on the work and emits an event at each transition. The read plane sits to one side and, when asked, counts how many ids are in each state right now. Neither moves a job. Step a job through its life to see both reports update.
One lifecycle, two reports · step the job
Two reports of one life: the meter says it as it happens, the read plane answers it when asked — and the work is untouched by either.
The dives
Three dives, the push side then the pull side then the property that ties them. Each grounds in the real
echo/apps/echo_mq code — the EchoMQ.Meter event surface,
its zero-cost-when-absent guard, and the EchoMQ.Metrics read plane.
The telemetry surface
The push side: EchoMQ.Meter — attach / emit / span and the lifecycle emitters, re-rooted under [:emq, …], one tree.
Zero cost when absent
The opt-in property: every emission guards function_exported(:telemetry, :execute, 3) — no dependency edge, no cost unless a host opts in.
The read plane
The pull side: EchoMQ.Metrics — counts, a job's state, throughput, the read-and-refuse gate. Every verb observes; none mutates.
Redis Patterns Applied
This is the depth behind the Redis Patterns Applied chapter that doors here:
R8 · Production Operations — the metering and
read-side introspection an operator runs a tier with, made concrete here as the EchoMQ.Meter
event tree and the EchoMQ.Metrics read plane. There the pattern is the door; here is the
surface.
The rest of the pillar
This module is how the proven system reports on itself. The conformance suite proves the contract holds; the benchmark gate is the named frontier. The pillar shows one thing three ways: the system holds, meters itself, and reads honestly.
The Proof
The pillar landing: the system holds, and it can show you.
The Queue
The lifecycle the meter and the read plane observe.
The Bus
Broadcast signals over the same wire; the connector meters on the same tree.
The Cache
Serve reads in front of the bus; coherence by branded id.
The conformance suite and the read plane are ready to read; the benchmark gate is the named frontier, added when its surface lands.
References
Sources
- Elixir — the :telemetry library — the standard metering surface the Meter re-roots under
[:emq, …]. - Erlang/OTP — :telemetry.execute/3 — the execute the guarded emit calls when the dependency is loaded.
- Valkey — ZCARD — the cardinality the read plane counts each state set by.
- Valkey — ZSCORE — the membership test the state lookup resolves an id by.
Related in this course
- The Proof — the pillar this module belongs to.
- The Queue — the lifecycle the meter and the read plane observe.
- The Protocol — the declared-keys law every read script obeys.
- Overview — the chapter that frames the three pillars.
- The Branded Component System · together — the manuscript chapter where the four libraries are one umbrella.