A single Redis node has one keyspace. A Redis Cluster spreads the keyspace across multiple primary nodes.

The routing model is:

key -> hash slot -> node responsible for that slot

Redis Cluster uses 16,384 hash slots. Every key maps to one slot, and every slot is owned by a primary node.

Slots Add A Layer Of Indirection

Redis could have mapped keys directly to nodes:

node = hash(key) mod numberOfNodes

That approach is simple until the number of nodes changes. Adding or removing a node remaps a huge portion of the keyspace.

Hash slots create an intermediate unit:

keys -> slots -> nodes

Now the cluster can move slots between nodes. The key-to-slot function stays stable, while slot ownership changes over time.

Hash Tags Keep Related Keys Together

By default, a key's slot is computed from the key. Conceptually:

slot = CRC16(key) mod 16384

Hash tags let applications force related keys into the same slot:

user:{42}:name
user:{42}:cart
user:{42}:settings

Only the substring inside {} is hashed, so these keys share a slot.

This matters because Redis Cluster restricts multi-key commands. If a command touches multiple keys, those keys usually need to be in the same slot.

MOVED Teaches Clients The Cluster

Clients may not always know the current slot map. If a client sends a command to the wrong node, the node can reply:

-MOVED slot host:port

That response tells the client where the slot actually lives. A cluster-aware client updates its local slot map and retries future commands at the correct node.

Redis Cluster therefore relies on smart clients. The cluster does not hide distribution behind a single coordinator for every command. Clients learn the topology and route directly.

Cross-Slot Commands Are Limited

Multi-key operations become tricky in a sharded system. If MGET a b touches keys in different slots, one node cannot execute the whole command locally.

Redis Cluster usually rejects such commands with a cross-slot error unless the keys hash to the same slot.

MGET user:{42}:name user:{42}:email  allowed
MGET user:42:name user:99:name       likely cross-slot

This shifts some modeling responsibility to application key design. Good cluster key naming is not aesthetic. It determines which operations remain possible.

Cluster Sharding Preserves The Redis Feel

Redis Cluster does not turn Redis into a transparent distributed SQL database. It keeps the command model local to a slot and uses redirection plus client routing to scale the keyspace.

The design is pragmatic. Fixed slots make ownership concrete. Hash tags give applications control. MOVED replies let clients adapt. Cross-slot restrictions keep command execution local and predictable.

Cluster mode is Redis accepting distribution without pretending that distribution has disappeared.