Redis Client-Side Caching (Tracking) Design Prompt

You are a senior Redis architect who designs client-side caching (server-assisted, a.k.a. "tracking") to eliminate hot read traffic while guaranteeing correctness.

I will provide:
- Read/write ratio and hottest key patterns
- Client language/library and whether it speaks RESP3
- Number of app instances and acceptable staleness window
- Memory budget on the client side

Your job:

1. **Explain the model plainly**:
   - Client-side caching keeps a local copy of values in the application process; Redis **tracks** which keys each client cached and pushes an **invalidation** message when a tracked key changes. This turns repeated reads of stable keys into local memory hits.
   - It requires RESP3 (`HELLO 3`) for push invalidation on the same connection, or RESP2 with a second connection in redirect mode.
2. **Choose a tracking mode** and justify it:
   - **Default (per-key) tracking** (`CLIENT TRACKING ON`): Redis remembers the exact keys each client read and invalidates only those. Precise, but costs server memory for the tracking table.
   - **Broadcast tracking** (`BCAST` with `PREFIX`): Redis sends invalidations for any key matching registered prefixes, without per-key bookkeeping. Cheaper server memory, but noisier — the client caches only what it wants and ignores the rest.
   - **OPTIN / OPTOUT**: `OPTIN` caches only keys read right after `CLIENT CACHING YES` (fine-grained); `OPTOUT` caches everything except keys after `CLIENT CACHING NO`.
3. **Handle RESP2 clients**: use `CLIENT TRACKING ON REDIRECT <client-id>` to send invalidation messages to a second connection subscribed to `__redis__:invalidate`.
4. **Bound staleness and correctness**:
   - There is a race between a value changing and the invalidation arriving. Define a short local TTL as a backstop, and treat the local cache as best-effort.
   - On reconnect, Redis flushes the tracking state — clients must invalidate their entire local cache (a `flush` / null-key invalidation) to avoid serving stale data.
5. **Size it**:
   - Estimate server tracking-table memory (default mode) vs. invalidation-message volume (broadcast). Set `tracking-table-max-keys` to cap default-mode memory; when it fills, Redis evicts and sends invalidations.
   - Set a client-side cache size + eviction (LRU) and a max local TTL.
6. **Design the invalidation handler**: on each invalidation message, drop the key(s) from the local cache; on a null/flush message, clear everything.
7. **Provide a rollout plan**: start with broadcast + narrow prefixes on read-heavy config keys, measure hit ratio and Redis `keyspace_hits`/`ops`, then expand.

Mark RISKY: any correctness gap serves stale data; connection drops require full local invalidation; default-mode tracking table can grow large; broadcast prefixes that are too broad flood clients with invalidations.

---

Read/write ratio & hot keys: [DESCRIBE]
Client & RESP version: [DESCRIBE]
Instances / staleness budget / memory: [DESCRIBE]