Consistent hashing solves the reshuffle problem, but the classic ring-based implementation costs memory and complexity: you keep hundreds of virtual nodes per real node in a sorted structure, do a binary search per lookup, and maintain that structure as the cluster changes. Jump consistent hash, published by Google engineers John Lamping and Eric Veach in 2014, throws all of that away. It's seven lines of code, uses zero memory, and distributes keys as evenly as the ring — with one catch we'll get to.

The algorithm answers a single question: given a key and a bucket count N, which of the N buckets does this key belong to? Here it is in C:

• int64_t b = -1, j = 0;
• while (j < num_buckets) {
•   b = j;
•   key = key * 2862933555777941757ULL + 1;
•   j = (b + 1) * ((double)(1LL << 31) / ((key >> 33) + 1));
• }
• return b;

That's it. No ring, no virtual nodes, no sorted set. The intuition: imagine adding buckets one at a time. When you go from n to n+1 buckets, each key should move to the new bucket with probability 1/(n+1). The loop uses the key as a PRNG seed to simulate that decision quickly, jumping ahead to the next resize event that would actually move this key instead of checking each bucket.

Real-world example: Google uses jump hash in their storage systems to map file chunks to servers. Say you're running a video CDN with 1000 edge nodes and you need to decide which node caches which video ID. With a ring, every lookup does a binary search over ~150,000 virtual node entries. With jump hash, every lookup is roughly log₂(1000) ≈ 10 iterations of a tight arithmetic loop — no memory access, no cache misses, no data structure to keep in sync across worker threads.

Rule of thumb: jump hash costs about O(ln N) per lookup and O(1) memory. For N = 1024 buckets, expect ~7 loop iterations. For N = 1 million, ~14. It's faster than ring lookup for any cluster size.

The catch: jump hash only handles adding or removing the last bucket cleanly. If bucket 47 fails in a 100-node cluster, you can't just "skip" it — you'd have to renumber, which reshuffles everything. This makes jump hash perfect for sharding (where you control bucket numbering and grow at the tail) and wrong for service discovery (where any node can die). Use rendezvous or ring hashing when arbitrary nodes disappear; use jump hash when you're allocating shards to a numbered pool.