How Redis Cluster Achieves Linear Scalability and High Availability

Scalable Design of Redis Cluster

Redis Cluster introduces the concept of hash slots to partition data; the cluster has 16,384 slots, and each node is responsible for a subset of these slots. For example, with three nodes the distribution could be:

Node A: slots 0‑5500

Node B: slots 5501‑11000

Node C: slots 11001‑16383

When a client accesses a key, Redis computes CRC16(key) mod 16384 to determine the slot, then routes the request to the node owning that slot. HASH_SLOT = CRC16(key) mod 16384 The hash‑slot mechanism enables dynamic scaling: adding or removing nodes triggers data migration at the granularity of slots, allowing near‑linear growth of storage and throughput without client disruption.

During migration, if a key’s slot is being moved from node A to node B, the cluster continues to direct requests to node A. If the key has already migrated, node A redirects the client to node B, which then serves the request. New keys for the migrating slot are created directly on the target node.

High‑Availability Design of Redis Cluster

Redis Cluster achieves high availability through master‑slave replication. Each master node has a replica (e.g., A1 replicates A). If a master fails, its replica is elected as the new master, and the cluster continues serving requests.

Failover steps (simplified):

Master A crashes; the cluster promotes A1 to master.

During the election, some read/write operations may fail.

When the original master restarts, it rejoins as a replica.

Redis favors performance over strong consistency because replication is asynchronous. The write flow is:

Client writes to master B.

Master B returns OK immediately.

Master B asynchronously forwards the write to its replica B1.

If master B crashes before the replica acknowledges the write, the data may be lost after failover, illustrating the classic performance‑vs‑consistency trade‑off.

Redis Cluster Client Considerations

Clients must be aware of the cluster topology. They need to configure multiple node IPs and cache the mapping between hash slots and nodes, allowing direct routing of commands to the appropriate node and improving performance.

The overall cluster design therefore involves both server‑side mechanisms (hash‑slot partitioning, replication, failover) and client‑side support (slot‑to‑node routing), which together deliver scalable and highly available Redis deployments.