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

## The question behind the question This is a design-rationale question. The interviewer wants to see whether you understand that the slot count is a tunable in the *control plane*, not a performance knob for the data plane, and that it was chosen by trading gossip overhead against rebalancing granularity. ## Constraint one: the cluster bus carries slot bitmaps Redis Cluster nodes talk to each other over a separate binary protocol - the cluster bus - on the client port plus 10000. They exchange heartbeats (PING/PONG) continuously: each node pings a few random nodes every second and guarantees every node is pinged at least once every `cluster-node-timeout/2`, so in a cluster of N nodes the total heartbeat rate grows with N. Every heartbeat header includes the sender's **slot bitmap**: one bit per slot, marking the slots the sender claims to own. This is how ownership propagates and how nodes detect configuration conflicts. One bit per slot means the bitmap size is directly proportional to the slot count: - 16384 slots = 16384 bits = **2 KB** per packet - 65536 slots = 65536 bits = **8 KB** per packet Multiply 8 KB by every heartbeat between every pair of nodes and the control plane starts eating meaningful bandwidth - for a feature (finer granularity) nobody needed. There is a second, subtler effect: in practice each node owns a few contiguous ranges, so the bitmap is highly compressible, but the compression ratio degrades as the bitmap grows relative to the number of ranges actually used. ## Constraint two: you need more slots than nodes, by a healthy factor A slot is the atomic unit of ownership and of migration. You can move a slot from one master to another; you can never split one. So the slot count sets the finest possible granularity of rebalancing: - If slots per node is 1, ownership is all-or-nothing and rebalancing is impossible. - If slots per node is small (say 4), moving one slot shifts 25% of a node's data - far too coarse to correct mild imbalance. - If slots per node is in the tens or hundreds, you can nudge load in small increments. Redis Cluster was designed with a practical ceiling of roughly 1000 master nodes (beyond that, gossip and failover coordination stop being comfortable). At 1000 nodes, 16384 slots give about 16 slots each - workable. At 65536 slots you would get 65 slots each, marginally better granularity that nobody needs, at 4x the gossip cost. At 1024 slots a 1000-node cluster would be degenerate. ## Why a power of two 16384 = 2^14, so `CRC16(key) mod 16384` is implemented as `crc & 16383` - a mask rather than a division. This is a micro-optimisation on a path executed for every key of every command, and it also makes the bitmap byte-aligned (2048 bytes exactly). ## What the number does *not* mean A few misreadings are common: - **It is not a node limit.** 16384 slots do not mean 16384 nodes are supported; the practical node ceiling is far lower and comes from gossip and failover behaviour, not from slot arithmetic. - **It is not configurable.** Unlike many sharded systems where you pick a partition count at creation time, Redis hard-codes 16384. Clients, the CRC16 implementation, the bitmap layout and the on-wire format all assume it. This is a feature: any client from any language computes the same slot without configuration discovery. - **It is not a capacity or performance limit.** A slot holds an unbounded number of keys. Having 16384 slots says nothing about how much data or throughput a cluster can handle. - **More slots would not improve balance for small clusters.** With 3 or 30 nodes, 16384 slots already give thousands of slots per node; imbalance in real clusters comes from key distribution (over-broad hash tags, giant individual keys), not from slot granularity. ## How to answer it in an interview Give the two-sided trade explicitly - bitmap bytes per heartbeat on one side, slots-per-node granularity at the design ceiling of ~1000 nodes on the other - and mention the power-of-two convenience. Then add the honest coda: for real clusters the number is simply a constant you never touch, and imbalance is a keyspace-design problem rather than a slot-count problem.