consistent-hashinglisted

# Consistent Hashing ## Purpose Own one function: given a key and a set of nodes, which node holds it — and how much of that mapping survives when a node joins or leaves. Nothing else in the partitioning family computes placement; this skill is where any hashing arithmetic belongs. The failure this prevents is `hash(key) % N`. With a sufficiently uniform hash it can distribute keys evenly, but it stays operationally stable only until N changes, at which point a large fraction may map somewhere new — for a cache a fleet-wide miss storm in one step, for a store a migration of nearly the whole dataset, discovered when someone adds a node to relieve pressure and the rebalance becomes the outage. The second failure is subtler: a ring with one point per node is _not_ well balanced, so a naive implementation gets minimal disruption while handing one node several times another's share. ## Workflow 1. **State the disruption and migration budget.** How many keys, bytes and requests may change owner, at what transfer rate, and under what availability target? `% N` can remap a large fraction; with equal nodes, a ring or rendezvous moves about K/(N+1) on a join and the removed node's approximately K/N share on a removal. 2. **Count the nodes.** With a small membership, rendezvous hashing is fewer moving parts than a ring and needs no virtual-node tuning. A ring earns its complexity at larger N or where lookup must be sub-linear. 3. **Specify the placement contract comp