skip to content

Hash Slots & Hash Tags

3 roadmaps5 questions

You will learn Redis Cluster's sharding unit — CRC16 of the key mod 16384 slots — and hash tags, the braces trick that pins related keys to one slot. Interviewers ask because slots and tags explain every other cluster behavior, from redirects to multi-key errors.

part ofRedisoverview, primer and where to startread it →
on this pageshow

explore

questions

5

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.

level: juniorimportance: must knowfreq 62%

answer

  1. CRC16(key) mod 16384 = slot
  2. two hops: key to slot, slot to node
  3. 16384 = 2^14, fixed, not configurable
  4. hash tag hashes only the braces content
  5. rebalancing moves slot ownership, never rehashes keys

basics

~20 s

Redis 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 s

Redis 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 lines
text
127.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) 2

go deeper

for a junior

Recall the formula and the two-step mapping: CRC16 mod 16384 gives the slot, and each slot belongs to one master.

for a middle

Add that hash tags override which substring is hashed, and that rebalancing moves slot ownership rather than rehashing keys.

for a senior

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.

for a principal

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

context

resolving links…

open as a page

What does wrapping part of a Redis key in curly braces, as in user:{1000}:profile, do to where the key is placed in a Redis Cluster, and when would you deliberately use that?

level: middleimportance: must knowfreq 55%

basics

~20 s

Curly braces form a hash tag: Redis hashes only the substring inside the first {...} instead of the whole key. Keys sharing a tag share a slot and therefore a node, which is how you co-locate keys that must be read or written together.

open as a page

A Redis Cluster starts rejecting commands with CLUSTERDOWN and CLUSTER INFO reports cluster_state:fail. Explain what hash-slot coverage means, how you identify which slots have no owner, and what the cluster-require-full-coverage setting changes.

level: seniorimportance: should knowfreq 34%

basics

~20 s

Coverage means all 16384 slots are claimed by a reachable master. If any slot has no owner, the cluster marks itself failed and, with cluster-require-full-coverage yes (the default), refuses every command - even for slots that are fine. Set it to no to keep serving the covered slots.

open as a page

How do you inspect which hash slots each Redis Cluster node owns, verify that two specific keys will be served by the same node, and how does a client library know where to send a command?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Use CLUSTER SHARDS (or the older CLUSTER SLOTS) for slot-range ownership, CLUSTER NODES for the raw view, and CLUSTER KEYSLOT on each key to compare slots. Smart clients fetch that map once, cache it, compute slots locally with CRC16, and refresh when the server says a slot moved.

open as a page

Redis Cluster uses exactly 16384 hash slots. Why that number rather than, say, 1024 or 65536?

level: middleimportance: nice to knowfreq 30%

basics

~20 s

16384 balances two forces: each cluster-bus heartbeat carries a bitmap of the sender's slots, so 16384 bits is 2 KB per packet while 65536 would be 8 KB; and since clusters are not expected to exceed roughly 1000 nodes, 16384 slots still give fine-grained rebalancing.

open as a page