Redis Cluster Setup: 6+ Nodes, Hash Slots, and Failover

Redis Cluster setup requires at least 6 nodes (3 masters + 3 replicas per the Redis docs). The cluster uses 16384 hash slots distributed across master nodes. Replicas provide failover via gossip-based replication. The team that needs >25GB single-node memory or >100K ops/sec has the cluster. Smaller workloads stay on single-node Redis.

Why cluster
Minimum 6 nodes
Hash slots
Cluster setup
Adding nodes
Failover
Client libraries
Managed alternatives
FAQ

Why cluster

Single Redis limits:

Memory: up to ~256GB on large instances.
Throughput: ~100K ops/sec single-threaded.
No automatic failover (without Sentinel).

Cluster provides:

Horizontal scaling (add nodes for more capacity).
Automatic failover (replica promoted to master).
Hash slot distribution (16384 slots across masters).

Minimum 6 nodes

3 masters + 3 replicas (one replica per master). Failover works:

Master fails -> replica promoted.
Need majority of masters alive for cluster to function (2 of 3).
Quorum-based decision making.

The team that runs 6 nodes has reliable cluster. The team that runs 3 nodes (no replicas) has no failover.

Hash slots

16384 hash slots distributed across masters:

# Cluster has 3 masters
Master 1: slots 0-5460
Master 2: slots 5461-10922
Master 3: slots 10923-16383

Keys are hashed (CRC16(key) mod 16384) to a slot. The cluster routes requests to the right master. The team that uses keys with hash tags (user:{1234}:profile) has related keys on the same node for multi-key operations.

Cluster setup

Create a redis cluster:

# Start 6 redis instances with cluster enabled
redis-server --port 7000 --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 --appendonly yes
# ... repeat for 7001, 7002, 7003, 7004, 7005

# Create the cluster
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
  127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

The team that uses redis-cli --cluster create has automated cluster bootstrap.

Adding nodes

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000
# Resharding
redis-cli --cluster reshard 127.0.0.1:7000

The team that adds nodes for capacity uses add-node then reshards to redistribute slots.

Failover

When a master fails:

Replica detects failure (within cluster-node-timeout, default 15s).
Replica initiates failover election.
Replica wins if majority of masters agree.
Replica promoted to master.
Other masters update their cluster view.

The team that uses cluster has automatic failover. The team that uses single-node Redis needs Sentinel for the same.

Client libraries

Cluster-aware clients (redis-py-cluster, lettuce, jedis) handle hash slot routing. Simple clients (redis-cli) need to be told which node to connect to (use -c for cluster mode).

Managed alternatives

AWS ElastiCache for Redis: managed cluster mode.
GCP Memorystore: managed Redis (limited cluster support).
Azure Cache for Redis: managed Redis with clustering.
Upstash: serverless Redis.
Redis Enterprise: commercial, advanced features.

The team that uses managed Redis has cluster ops handled by the provider.

FAQ

How many nodes do I need for Redis cluster?

Minimum 6 (3 masters + 3 replicas) for HA. The team that runs 3 masters without replicas has no failover.

Can I have a cluster with different master/replica counts?

Yes - asymmetric setups work (e.g., 3 masters + 6 replicas for read-heavy). The team that needs more read capacity adds more replicas.

How does cluster handle multi-key operations?

Only works if keys are in the same hash slot. Use hash tags: user:{1234}:profile and user:{1234}:settings are in the same slot (the part in {}).

Can I run Redis cluster on Kubernetes?

Yes - Redis operator (e.g., redis-operator from Spotahelm) manages cluster mode in K8s. Or use managed services.

What’s the cost of cluster mode?

More nodes = more memory + CPU. The team that picks cluster mode for >100K ops/sec or >25GB has the cost offset by capacity.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: