Redis has a CLIENT TRACKING feature used with the RESP3 protocol. What problem does it solve, and how does an application learn that a value it has cached locally is no longer valid?

## The problem: a hit still costs a round trip A Redis GET is microseconds of server work, but the round trip is typically 0.1-0.5 ms inside a datacenter. For a value read thousands of times per second per process — a feature flag, a config blob, a permission set, a hot catalog entry — that adds up to real latency and real load on one Redis node. The obvious fix is to keep the value in the application's own memory. The hard part is invalidation: the process now holds a copy that nothing tells it to drop. The traditional workarounds are a short local TTL (accept bounded staleness), or a Pub/Sub channel your application publishes invalidations to (works, but every writer must remember to publish, and it is your code's job to get right). **CLIENT TRACKING** makes the server responsible for the telling. ## RESP3 and push messages RESP2, the classic Redis protocol, is strictly request/response on a connection: the server only speaks when spoken to. The single exception was Pub/Sub, which effectively takes the connection over. RESP3 (introduced in Redis 6.0, and requested by the client sending `HELLO 3`) adds a **push** message type: out-of-band data the server can deliver on a normal connection, interleaved with ordinary command replies, and distinguishable from them. Client-side-caching invalidation rides on that. This is why tracking is described as a RESP3 feature even though a RESP2 fallback exists. ## What the server remembers In the default tracking mode, the server maintains one global **invalidation table**: a mapping from key name to the set of client IDs that have recently read that key. It is intentionally approximate and memory-bounded by `tracking-table-max-keys` (default 1,000,000). When the table is full, Redis evicts entries and, to stay safe, **sends invalidation messages for the evicted keys** — clients may receive an invalidation for something that did not actually change. Spurious invalidations are harmless (an extra miss); missed ones would not be, so the design errs that way. Caching keys are remembered when a read command touches them. Invalidations fire when a key is **modified, expired, or evicted** — all three, because from the client's point of view all three mean "your copy is no longer what Redis has". ## The wire flow ``` HELLO 3 CLIENT TRACKING on GET config:v1:flags -> "{...}" # server now tracks this key for this client # ... application caches the value locally, serves it from memory ... # elsewhere: SET config:v1:flags "{...new...}" >2 # push message "invalidate" 1) "config:v1:flags" # client drops its local copy ``` A push with a **null** key array means flush the entire local cache; the server sends it on `FLUSHALL`/`FLUSHDB`. ## The RESP2 fallback: REDIRECT If your client library cannot speak RESP3, `CLIENT TRACKING on REDIRECT <client-id>` routes this connection's invalidation messages to a **different** connection — one that has subscribed to the special Pub/Sub channel `__redis__:invalidate`. You get the same information at the cost of managing two connections and their lifecycles. If the redirect target disconnects, tracking is broken; the server notifies the tracking client with a `tracking-redir-broken` push (RESP3) so it knows to flush and re-establish. ## NOLOOP and other options `CLIENT TRACKING on NOLOOP` suppresses invalidations for keys **this** client itself modified — useful when the writer already knows it invalidated its own copy and does not want the echo. There are also `BCAST` with `PREFIX`, and `OPTIN`/`OPTOUT` modes for controlling *which* keys get tracked; those are large enough topics on their own. `CLIENT TRACKINGINFO` (Redis 6.2) reports the current connection's mode, prefixes, and redirect target, which is the first thing to run when debugging. ## What it is not This is **best-effort invalidation, not coherence**. There is a real window between a key changing and the push arriving, during which the local copy is stale — bounded by network latency plus client processing, but not zero. There is no acknowledgement, no versioning, and no guarantee against loss if the connection breaks. So the local cache still needs the ordinary defenses: a **local TTL** as a backstop, a **bounded size** with local eviction (an unbounded in-process map is a memory leak), and a **flush on reconnect**, since anything that happened while the connection was down was never delivered. Treat tracking as an accelerator that shortens staleness from "the local TTL" to "a few milliseconds", not as a guarantee that removes the need for the TTL. ## Where it pays The wins are largest for values with a very high read-to-write ratio and a small working set: configuration, feature flags, entitlement lookups, small reference data. It pays poorly for large working sets (you will not fit them in process memory anyway) and for write-heavy keys, where the invalidation traffic can exceed the savings. In Redis Cluster, tracking is per connection to each node, so a client must enable it on every node connection it uses.