Consistent Hashing and Data Placement

A distributed cache needs a repeatable way to decide which server holds a key. A simple hash remainder can spread keys, but changing the number of servers can change many assignments. Consistent hashing is a placement technique intended to limit movement when membership changes.

It chooses an owner; it does not make a key durable, replicate it or keep two writers consistent. Those responsibilities need separate mechanisms.

Imagine a circle of positions. Hash each server identity and key onto the circle. Assign a key to the next server clockwise, wrapping to the beginning when needed. Adding a server takes over the interval just before that server instead of redefining the whole circle.

Real systems often give each server several positions called virtual nodes. This can improve distribution and allow weighting by capacity. The quality of the hash and the number of positions matter; a tiny diagram is not a prediction of production balance.

Compare twelve fixed key hashes, 0 through 11. Remainder mode uses hash modulo server count. Ring mode uses a twelve-position circle with A at 0, B at 4, C at 8 and optional D at 10; the next clockwise server owns the key.

Turn on D and compare each key’s old and new owner. The positions are deliberately small and chosen for explanation. Real hashes use a much larger space and usually virtual nodes; this example does not model migration or cache recovery.

If two clients use different server lists, they can send the same key to different owners. Publish membership changes deliberately and define how old and new owners coexist during migration. Database resharding needs data transfer, write routing and verification; updating a ring alone does not migrate records.

A cache may refill missing values from authoritative storage, but simultaneous misses can overload that source. Pace warming and keep rollback information. A single extremely popular key can still overload its one owner; replication, request coalescing or a different access pattern may be needed.

Some systems assign fixed partitions to servers through a directory. Redis Cluster, for example, uses hash slots rather than this exact next-clockwise-server model. Rendezvous hashing ranks servers per key and is another placement approach. Compare membership coordination, weighting and migration before choosing.

Use Redis Cluster’s specification for its actual slot and migration behaviour. Throughput still depends on value size, command cost, hit rate and hot keys; a placement algorithm has no universal requests-per-second rating.

Use placement to reduce movement, then design the transition and hot-key path. Continue with sharding for the broader data migration problem.