In Redis Cluster, how does the system decide which node stores a given key? Walk through the computation from the key string to the node that serves it.
answer
- CRC16(key) mod 16384 = slot
- two hops: key to slot, slot to node
- 16384 = 2^14, fixed, not configurable
- hash tag hashes only the braces content
- rebalancing moves slot ownership, never rehashes keys
basics
~20 sRedis Cluster computes CRC16 of the key modulo 16384, giving a hash slot. Each of the 16384 slots is owned by exactly one master node, so the slot decides the node. Keys are never hashed against node addresses.
solid answer
~50 sRedis Cluster shards by **hash slot**, not directly by node. The keyspace is statically divided into 16384 slots. For any key the server computes `CRC16(key) mod 16384`, where `key` is the whole key name unless it contains a hash tag, in which case only the substring inside the first `{...}` is hashed. That yields a slot number in 0..16383. Separately, slot *ranges* are assigned to master nodes (e.g. node A owns 0-5460, B owns 5461-10922, C the rest). Routing is therefore two lookups: key to slot (a pure function, identical on every node and every client, forever) and slot to node (cluster state, gossiped on the cluster bus and cached by smart clients). Because the key-to-slot function never changes, rebalancing moves slot *ownership* rather than rehashing keys. `CLUSTER KEYSLOT foo` shows a key's slot; `CLUSTER SHARDS` shows which node owns it.
code
text · 8 lines127.0.0.1:7000> CLUSTER KEYSLOT user:1000:profile
(integer) 1649
127.0.0.1:7000> CLUSTER KEYSLOT "user:{1000}:profile"
(integer) 5288
127.0.0.1:7000> CLUSTER KEYSLOT "orders:{1000}"
(integer) 5288
127.0.0.1:7000> CLUSTER COUNTKEYSINSLOT 5288
(integer) 2go deeper
Recall the formula and the two-step mapping: CRC16 mod 16384 gives the slot, and each slot belongs to one master.
Add that hash tags override which substring is hashed, and that rebalancing moves slot ownership rather than rehashing keys.
Explain why fixed slots beat a consistent-hashing ring operationally - enumerable ownership, a well-defined migration unit, verifiable full coverage - and how clients cache the map.
Frame it as a client-assisted sharding design with no proxy in the data path, and discuss what the fixed slot granularity implies for imbalance and for keyspace design.
## The two-level mapping Redis Cluster deliberately does not hash keys onto nodes. It inserts a fixed intermediate layer called the **hash slot**. There are exactly 16384 slots, numbered 0 to 16383, and the entire keyspace is partitioned across them. Routing has two independent steps: 1. **key to slot** - a pure function, `CRC16(key) mod 16384`. It depends on nothing but the key bytes, so every node, every client library and `redis-cli` compute the same answer, and the answer never changes over the life of the cluster. 2. **slot to node** - cluster state. Each master claims a set of slot ranges; that ownership map is shared between nodes over the cluster bus (a separate binary gossip protocol on port + 10000) and handed to clients on request. Separating the two is the whole design. Adding or removing a node changes only step 2: some slots change owner and their keys are migrated. Step 1 is untouched, so no key ever needs to be recomputed, and a client that knows the key can compute the slot offline without talking to anyone. ## The hash function Redis uses CRC16 in the XMODEM/CCITT variant over the raw key bytes, then masks to 14 bits (`mod 16384` is exactly `& 16383` since 16384 = 2^14). CRC16 is not a cryptographic hash; it was chosen because it is extremely cheap and distributes ordinary key names - which share long common prefixes like `user:1000:profile` - evenly across slots. Uniformity in the low bits is what matters here, not collision resistance. Two different keys landing in the same slot is normal and harmless: a slot holds an arbitrary number of keys. ## The hash-tag exception If the key contains a `{`, and after it a `}` with at least one byte between them, Redis hashes **only that inner substring**. `user:{1000}:profile` and `orders:{1000}` both hash `1000` and therefore share a slot. Everything else about the key is ignored for routing purposes. This is the single escape hatch that lets an application place related keys together deliberately. ## From slot to node Every master in the cluster owns a subset of the 16384 slots; in a healthy cluster the union of all owned slots is the full range and no slot has two owners. Replicas own no slots of their own - they mirror their master's. The mapping is not a range partition of the key space (keys are not ordered), just an arbitrary assignment of slot numbers, which is why an operator can move individual slots to correct imbalance. If a client sends a command to the wrong node, the node does not proxy it. It answers with a redirect telling the client which node owns that slot, and a well-behaved client refreshes its cached slot map and retries. Redis Cluster is therefore a *client-assisted* sharding design: there is no router process in the data path, which is why latency stays close to single-instance Redis. ## Why not consistent hashing A classic consistent-hashing ring maps keys onto node identities via a hash of the node address, so the set of keys a node owns changes implicitly whenever membership changes, and ownership is hard to state exactly. Fixed slots give explicit, enumerable ownership: a slot is either yours or not, migration is a well-defined unit of work, and the cluster can verify that all 16384 slots are covered. It also makes hash tags meaningful - co-location is a property of the slot, and the slot is what moves. ## Practical consequences - Multi-key commands only work when all keys are in one slot, because a single node must be able to execute them locally. - Slots are the unit of migration and of imbalance. A single slot cannot be split, so a slot that holds a disproportionate share of data (usually because of an over-broad hash tag) cannot be relieved by rebalancing. - `CLUSTER KEYSLOT <key>` asks the server to run the same function for you; `CLUSTER COUNTKEYSINSLOT <slot>` tells you how many keys are in a slot; `CLUSTER SHARDS` (Redis 7.0+, replacing `CLUSTER SLOTS`) prints ownership. - Because the key-to-slot function is public and stable, clients precompute slots to route commands and to group pipelined commands per node. ## Common confusion The number of slots is fixed at 16384 and is not configurable, and it is unrelated to the number of nodes. A three-node cluster and a thirty-node cluster both have 16384 slots; they differ only in how many slots each node owns. Similarly, slots are not databases: cluster mode supports only database 0.
- If the key-to-slot function is fixed, how does adding a fourth node to a three-node cluster change anything?Only slot ownership changes. The operator assigns a subset of slots from the existing masters to the new node, and the keys currently living in those slots are migrated to it. No key changes its slot number, and clients keep computing slots exactly as before - they just refresh the slot-to-node map.
- Do replicas own slots?No. Slot ownership belongs to masters; a replica serves as a copy of its master's slots and is advertised alongside it in CLUSTER SHARDS. Replicas answer reads only if the client opts in explicitly, and on failover the promoted replica takes over the master's slot ownership.
Slots are like the 16384 numbered pigeonholes in a mailroom: the address on a letter always maps to the same pigeonhole, and reorganising staff just reassigns which clerk empties which pigeonholes.
saying these in an interview costs you the question
- Saying Redis Cluster uses consistent hashing with a ring of node hashes
- Thinking the slot count is tuned to the number of nodes or is configurable
- Believing a node proxies a command for a key it does not own
- Assuming keys with the same prefix automatically land on the same node
- Confusing hash slots with the 16 numbered databases of standalone Redis