Client-side caching, and the invalidation Redis pushes

A local in-process cache in front of Redis removes the round trip and has no way to know when the value changed — which is why almost nobody does it.

> CLIENT TRACKING on

# now the server remembers which keys this connection read,
# and pushes an invalidation message when one changes.

> CLIENT TRACKING on BCAST PREFIX cache: 
# or: track by prefix, without per-key bookkeeping on the server

The broadcasting mode is the one that scales, because per-key tracking costs the server memory proportional to the number of connections times the keys they touched. The invalidation is a push message on the same connection, which is why RESP3 is a prerequisite. It is genuinely useful for a small set of hot, rarely changing values — a feature flag table, a configuration blob — and is overhead for anything else.