Under the Hood: Redis Enterprise Cluster

#redis #architecture #underthehood #opensource

Welcome to another post in the "Under the Hood" series.

The power of Redis lies in its simplicity. One thread, one event loop, zero locks.

Single-threaded execution eliminates the "lock contention" that slows down traditional databases.
Limitation: A single process can only utilise one CPU core. On a 64-core server, 98% of your hardware sits idle.

Redis Core Design

To scale, Redis Enterprise doesn't make the engine "bigger"; it makes the fleet smarter.

Key Design Decisions

One Core to Many (Multi-Tenancy)

Instead of one massive process, Enterprise runs multiple Redis Cores (shards) on a single node.

From Gossip to Proxy

Standard Redis Clusters use a Gossip Protocol. The client must "know" the cluster topology and handle redirections.
Solution: The Zero-Latency Proxy acts as the "Front Desk". The client talks to one endpoint; the proxy handles the complexity. It is multi-threaded and uses cut-through routing to ensure the "hop" is sub-millisecond.

Separation of Concerns (Control Plane)

Distributed Cluster Watchdogs oversees failovers and promotions. By separating the Data Path (Redis shards) from the Control Plane (watchdogs), the database can heal itself without interrupting traffic.

Note: In the diagram, it may seem the watchdogs are coupled with the Redis shards, but in reality, they just share the hardware space for resource efficiency.