Mastering Redis 6 Client‑Side Caching: Modes, Benefits, and Practical Demo

Redis 6 introduces client‑side caching, a feature that lets application servers keep copies of selected keys in their own memory, reducing latency and load on the Redis server.

Two Tracking Modes

Redis supports two tracking modes: the default mode, where the server records which keys each client has accessed and sends invalidation messages when those keys change; and the broadcast (BCAST) mode, where the server does not track keys but broadcasts invalidations to all clients that have enabled tracking for a given key prefix.

Advantages

Local memory reads avoid network round‑trip, speeding up access.

Fewer requests to the Redis server lower its load.

In distributed setups the built‑in invalidation eliminates the need for custom Pub/Sub to keep caches consistent.

Common Misconception

Client‑side caching is not a server‑side cache; Redis only notifies the client that a cached key is stale. The client must implement the actual storage and eviction logic.

Demo – Prerequisites

Requires Redis 6.x and a telnet client. Installation guides for Linux and Windows are linked in the original article.

1. Default Mode Demo

Enable tracking with the client tracking on command (disabled by default). Example telnet session:

<code>telnet 127.0.0.1 6379
hello 3
# enable tracking
client tracking on
# disable tracking
client tracking off
</code>

After enabling tracking, the server records each key accessed by the client. When another client modifies a key that was previously read, the first client receives a PUSH invalidation message.

The PUSH message format (RESP3) looks like:

<code>&gt;2
$10
invalidate
*1
$4
user
</code>

If a cached key expires or is evicted, the server also sends a PUSH message.

2. Broadcast Mode Demo

Enable broadcast mode with client tracking on bcast . The server no longer tracks which keys each client accessed; instead it broadcasts invalidations to all tracking clients.

<code>client tracking on bcast
</code>

Clients can filter messages by subscribing only to keys with a specific prefix:

<code>client tracking on bcast prefix myprefix
</code>

Only invalidations for keys starting with the chosen prefix are received, reducing unnecessary traffic.

3. Redirect (Forward) Mode Demo

For clients using the older RESP2 protocol, Redis provides a redirect (forward) mode that forwards tracking invalidations via the Pub/Sub channel _redis_:invalidate . Enable it with:

<code>client tracking on bcast redirect [client-id]
</code>

The target client obtains its client id via the client id command and subscribes to the channel:

<code>subscribe _redis_:invalidate
</code>

The received message is a RESP2 batch reply that conveys the same invalidation information.

Summary

Redis 6 client‑side caching offers a powerful way to move frequently accessed data from the server to the application layer, cutting latency and easing server load. Understanding the default, broadcast, and redirect modes—and their trade‑offs—allows developers to choose the most suitable approach for their architecture and to implement it with simple telnet commands and Pub/Sub subscriptions.