Valkey under the Exchange Platform.

The Exchange Platform reaches Valkey through one owned boundary — the echo data layer — and every surface, from the order 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: EchoCache, 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.

Below the facade the store does two distinct jobs, and the two roles ground different halves of the catalog. The cache machine is EchoCache. 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.

Each dive takes one part of the placement. Read them in order — the facade seam starts.