Redis 6 Client‑Side Caching: Concepts, Modes, and Practical Demonstrations

Introduction

Redis 6 introduces a new feature called client‑side caching that allows applications to cache data both on the application server and in the remote Redis cache, improving performance and reducing latency without adding extra middleware such as Caffeine.

Overview of Client‑Side Caching

Client‑side caching stores frequently accessed keys in the memory of the application server. When a cached key changes on the Redis server, the server sends an invalidate (push) message to the client, prompting it to discard the stale entry.

Client‑side caching creates high‑performance services by leveraging available memory on application servers, dramatically reducing data‑access latency and easing load on the Redis server.

Two Tracking Modes

Redis supports two tracking modes, both enabled via the client tracking command:

Default mode : The server records which client accessed which key . When the key’s value changes, an invalidate message is sent only to those clients that have accessed it.

Broadcast mode (BCAST) : The server does not record key accesses; instead, it broadcasts invalidation messages to all clients that have tracking enabled, optionally filtered by a key prefix.

Advantages Over Traditional Caching

Local reads avoid network round‑trips, reducing latency.

Fewer reads to Redis lower its load.

In distributed environments, native invalidation messages replace manual Pub/Sub coordination, ensuring cache consistency.

Common Misconception

Although called "client‑side caching," Redis itself does not store data on the application server; the client library must implement the local storage and handle invalidation messages.

Function Demonstration

The following sections show how to enable and use each mode with command‑line examples (telnet/RESP3) and the required Redis commands.

1. Default Mode

Enable tracking:

client tracking on

After a client reads a key (e.g., GET user ) and another client modifies it ( SET user "new" ), the first client receives an invalidate push message:

>2
$10
invalidate
*1
$4
user

Note that each key generates at most one invalidation message per client until the client accesses the key again.

2. Broadcast Mode

Enable broadcast tracking (optionally with a prefix filter):

client tracking on bcast

All clients with tracking receive invalidation messages for any changed key, or only for keys matching the specified prefix:

client tracking on bcast prefix myprefix

3. Forward Mode (for RESP 2 Clients)

When a client uses the older RESP 2 protocol, it can still receive invalidations via a redirect to a Pub/Sub channel:

client tracking on bcast redirect [client-id]

The target client subscribes to _redis_:invalidate and receives the same invalidation information in a RESP 2 batch format.

Summary

Redis 6 client‑side caching provides a flexible way to keep data close to the application, reduce latency, and simplify cache coherence without extra middleware. Depending on memory constraints and message‑traffic tolerance, developers can choose the default, broadcast, or forward mode to best fit their architecture.

Official documentation: https://redis.io/docs/manual/client-side-caching/