Redis's CLIENT TRACKING command accepts OPTIN and OPTOUT modes, paired with a CLIENT CACHING yes|no command. What do they control and why would you want that control?

## The default is indiscriminate With plain `CLIENT TRACKING on`, Redis records **every key the connection reads** into its global invalidation table, mapping key to the set of interested client IDs. That is a fine default and matches the common case — an application that locally caches whatever it fetches. But real applications read plenty of things they will never cache locally: a 4 MB blob fetched once for an export job, a per-request one-shot lookup that will never be read again, a scan of many keys during a batch. Tracking those costs on both sides: - **Server memory.** Each tracked key consumes an entry in the invalidation table, capped by `tracking-table-max-keys` (default 1,000,000). Filling the table with keys nobody caches pushes out entries for keys clients *do* cache, and evictions from that table trigger spurious invalidations to real consumers. - **Network and CPU.** Every modification of a tracked key produces a push message to each interested client. If the client is going to drop the message on the floor because it never cached the key, that traffic was pure waste — and on a write-heavy key it can be a lot of traffic. OPTIN and OPTOUT exist to align what the server tracks with what the client actually caches. ## OPTIN — whitelist `CLIENT TRACKING on OPTIN` turns tracking off by default for this connection. Nothing is remembered unless the client explicitly says so, per read, by sending `CLIENT CACHING YES` **immediately before** the read command: ``` CLIENT TRACKING on OPTIN GET session:v1:abc # NOT tracked CLIENT CACHING YES GET config:v1:flags # tracked GET config:v1:flags # NOT tracked again (the flag applied to one command) ``` The key subtlety: the caching flag is **valid for the next command only**. If that next command is `MULTI`, it applies to the whole transaction up to `EXEC`. It does not persist, so a client library that wants a key tracked must emit the pair every time — usually written into the same pipeline batch so it is still one round trip. OPTIN suits applications where a small, known set of keys is locally cacheable — configuration, flags, reference data — and the bulk of traffic is one-shot. ## OPTOUT — blacklist `CLIENT TRACKING on OPTOUT` inverts it: everything read on this connection is tracked, except commands preceded by `CLIENT CACHING NO`. ``` CLIENT TRACKING on OPTOUT GET user:v1:42 # tracked CLIENT CACHING NO GET export:v1:bigblob # NOT tracked ``` This suits applications where nearly everything is locally cached and the exceptions are identifiable — very large values you would never hold in process memory, or keys known to churn constantly. ## Mutual exclusivity and BCAST You cannot enable both: `CLIENT TRACKING on OPTIN OPTOUT` is rejected, and switching from one to the other requires turning tracking off first. Attempting `CLIENT CACHING` when tracking is off, or in the mode where it makes no sense (a `YES` under OPTOUT, a `NO` under OPTIN), is an error rather than a silent no-op — which is helpful, because it surfaces client-library bugs immediately. Neither mode combines with `BCAST`. In broadcast mode the server does not remember per-key interest at all; it broadcasts invalidations for registered key prefixes, so the prefix list *is* the selection mechanism and a per-command opt-in would have nothing to attach to. Redis rejects the combination. ## Practical notes - **Who emits these?** Almost always the client library, not application code. A well-built client exposes "cacheable" as a per-call hint and translates it into the `CLIENT CACHING` prefix, batching it with the read so no extra round trip is paid. - **Diagnosing.** `CLIENT TRACKINGINFO` reports the connection's flags, and you will see `optin`/`optout` plus a transient `caching-yes`/`caching-no` when a flag is pending for the next command. It is the fastest way to confirm the library is doing what you think. - **Choosing.** Estimate the ratio: if under roughly half your reads are locally cached, OPTIN; if the large majority are, OPTOUT; if the cacheable set is neatly described by key prefixes and you have very many connections, consider BCAST instead, which sidesteps per-key bookkeeping entirely. - **It changes tracking, not correctness.** An untracked key is simply one you will not be told about — so if the client caches it anyway, it will be stale forever. Whatever the mode, the rule stays: only locally cache what is tracked, and always keep a local TTL as a backstop.