Server-assisted client-side caching.

Client-side caching creates a multi-tier cache. L1 (local memory) is nanosecond access, held by the application; L2 (Valkey) is microsecond to millisecond access; L3 (the database) is millisecond access. The key innovation is that the server records which keys each client holds and sends an invalidation message when those keys change.

The payoff is the round-trip a cache-aside hit still pays. With cache-aside the data is in Valkey, one network hop away; a hit is fast but still a request and a response across a socket. For a key read thousands of times a second and changed rarely — an instrument record, a feature flag, a config blob — that hop is pure overhead. A near cache removes it: a repeated read of an unchanged key is a memory lookup with no network at all, and the value stays correct because the server pushes a message the moment it goes stale. This is exactly the shape of EchoCache (echo/apps/echo_cache): an L1 ETS table in the caller's process over an L2 Valkey row, with coherence carried by a server-side push.

Default tracking. The server remembers which keys each client has requested. After CLIENT TRACKING ON, every GET causes the server to record that this client accessed that key; if another client modifies the key, an invalidation message is pushed to the original client. The trade-off is that the server must maintain a table mapping keys to client IDs, consuming memory proportional to the number of tracked keys.

Broadcasting mode. Instead of recording individual key accesses, clients subscribe to key prefixes; the server broadcasts invalidation messages to all subscribers when any matching key changes. A client running CLIENT TRACKING ON BCAST PREFIX user: PREFIX session: receives invalidations for any key starting with user: or session:. The trade-off reverses: a client may receive invalidations for keys it does not have cached locally, but server memory stays minimal because it tracks prefix subscriptions, not individual accesses. EchoCache rides the broadcast shape over plain pub/sub: a table subscribes to one channel, ecc:{<table>}:coh, and the writer publishes a message naming the changed key.

How invalidation works. When tracking is enabled and a key changes, four steps follow. The server checks which clients hold the key; it sends an invalidation message naming the key; the client removes the key from its local cache; and the next access fetches fresh data. This keeps local caches synchronized without polling. The message names the key and carries no value — it reports only that the held copy is no longer trustworthy. In EchoCache the message carries one more thing than a bare CLIENT TRACKING invalidation does — the writer's mint-time version — so a late stale message can never erase a newer row.

This pattern benefits ultra-high-throughput applications where network RTT matters, frequently accessed "hot" keys, read-heavy workloads with relatively stable data, and applications already holding local caches that need invalidation.

Three considerations bound it. Memory management — the application must cap its local cache size, evicting when memory is constrained. Complexity — handling invalidation messages requires dedicated connection management or async processing. Not for volatile data — if data changes constantly, invalidation traffic may exceed the benefit of caching. RESP3 carries push notifications natively, making invalidation handling cleaner; EchoCache requires it for the broadcast lane — the table opens a RESP3 connection precisely so a push and a reply can share one wire.

The near cache the Exchange Platform would put in front of its instrument catalog is an EchoCache table: an L1 ETS row in the caller's process over an L2 Valkey row keyed ecc:{instruments}:<id>. Coherence is carried by a server push, not by polling. On start the table opens a RESP3 connection and subscribes to its coherence channel; when a writer changes a row, it publishes the change on that channel, and every subscribing table applies it newer-wins in its owner.

The module takes the pattern in three steps, in the arc track → invalidate → the same shape elsewhere: how the server records what each client holds, how it notifies a holder when a key changes, and a real EchoMQ script cache that follows the identical cache-then-invalidate idea. Read them in order — CLIENT TRACKING starts.