STANDARDwalkthrough

Jump Consistent Hashing

7 of 8
3 related
Google published Jump Hash in 2014 as a zero-memory alternative to ring-based consistent hashing. The algorithm uses a PRNG seeded by the key to 'jump' through bucket assignments, producing a bucket number in O(lnN)O(\ln N) time with no ring or vnode table.
When N changes from 100 to 101, exactly 1/1011/101 of keys remap. Why not always use jump hash?
Output is perfectly uniform: each of N buckets gets exactly 1/N1/N of keys.
It assumes sequential bucket numbering 0 to N-1. You cannot remove bucket 47 and keep 0-46 and 48-100.
Removal cascades. This makes jump hash ideal for append-only scaling but unsuitable for clusters where nodes fail at arbitrary positions.
We chose ring + vnodes because our cache cluster needs arbitrary node removal. Jump hash fits better for static datasets like log partition assignment.
Trade-off: jump hash has zero memory and perfect distribution, but cannot handle arbitrary removal.
Why it matters in interviews
Mentioning jump hash shows you know multiple algorithms and can articulate why the ring wins for caches (arbitrary removal) while jump hash wins for static partitioning.
Related concepts