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. With a sufficiently uniform hash, `hash(key) % N` can distribute keys evenly, but changing N can remap a large fraction depending on the divisors and node-index mapping. A cache can incur miss/refill traffic; a store may need to migrate changed ownership. The operational cost depends on the moved keys' bytes and request share, surviving copies and the handoff/refill policy. Adding capacity can trigger overload when those costs exceed the recovery budget; key movement alone does not establish a miss storm or 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 Reuse the existing placement/configuration and supplied workload evidence before asking questions. Establish whether the owner holds authoritative state, a recomputable cache entry or only affinity; ask only about unresolved durability, failure-domain or movement constraints that change the choice. Keep a sound current mapping when it meets those constraints. Apply only the relevant branches below. 1. **State the disruption and migration budget.** How many keys, bytes and requests ma