Mastering Redis Client‑Side Caching: How Tracking Ensures Data Consistency

Background

In May 2020 Redis 6.0 introduced many new features such as client‑side caching, ACL, threaded I/O, and Redis Cluster Proxy. This article focuses on client‑side caching, exploring why it is needed, its underlying principles, and how to use it.

1 Why client‑side caching is needed

1.1 Purpose of caching

Redis performs reads and writes entirely in memory, offering far higher performance than persistent storage like MySQL or files that require disk I/O. A latency hierarchy shows that memory access (e.g., L1 cache at 0.3 ns) is orders of magnitude faster than SSD (50‑150 µs) or remote storage (30 ms). Caching aims to accelerate access to data that would otherwise require slower disk reads, often delivering 10‑100× speedups over relational databases.

Data flow: hot data resides in Redis; when a request arrives, the system checks the cache first, falling back to the database only if the key is missing, thus improving overall read efficiency.

1.2 Existing problems

Even with Redis, latency is introduced by connecting to the cache service, I/O operations, network transmission, and serialization/deserialization. To further reduce latency, a local (process) cache such as Memcached or Guava Cache can be used as a first‑level cache, with Redis as a second‑level cache. The local cache avoids connection and network overhead, dramatically reducing data latency.

2 Client‑side caching implementation

Redis implements client‑side caching via the tracking feature, configurable with the CLIENT TRACKING command.

<code>CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]</code>

The core challenge is notifying clients promptly when a cached key changes or becomes invalid.

Redis 6.0 offers two main schemes for consistency:

Forwarding mode for RESP2 protocol

Normal and broadcast modes for RESP3 protocol

2.1 Normal mode

In normal mode, Redis stores client‑key mappings in a TrackingTable implemented as a radix tree. When a client accesses a key, enableTracking records the mapping. Upon key deletion or modification, the radix tree looks up the affected client IDs, sends an invalidation message via sendTrackingMessage , and removes the mapping.

<code>CLIENT TRACKING ON|OFF</code>

2.2 Broadcast mode (BCAST)

Broadcast mode uses a Prefix Table that maps prefix strings to client data (client ID list plus keys to notify). When a key changes, Redis checks the Prefix Table, iterates matching prefixes via trackingRememberKeyToBroadcast , and during the beforeSleep event sends broadcast invalidation messages, then clears the mapping.

2.3 Forwarding mode

RESP3 clients can push invalidation messages directly, but RESP2 clients cannot. To bridge this gap, a RESP3 client forwards invalidation messages to a Pub/Sub channel ( redis:invalidate ) that RESP2 clients subscribe to.

<code># Redis Client 2 (RESP2) subscribes
subscribe _redis_:invalidate

# Redis Client 1 (RESP3) forwards
CLIENT TRACKING ON BCAST REDIRECT 888</code>

3 Summary

3.1 Normal mode

The server records keys accessed by each client and sends invalidation messages when those keys change.

This consumes memory for the tracking table but keeps network and CPU overhead low.

Advantage: saves CPU and bandwidth; drawback: memory usage.

3.2 Broadcast mode

The server stores prefix mappings instead of individual keys, reducing memory consumption.

More CPU is spent on prefix matching.

Advantage: lower memory; drawback: higher CPU load.

3.3 Forwarding mode

Provides compatibility for RESP2 clients by forwarding invalidation messages via Pub/Sub.

Advantage: minimal memory usage; drawback: increased CPU.

Client‑side cache implementation

The application must implement its own local cache; Redis only notifies about key changes (deletions or additions).