Ring-based consistent hashing has a dirty secret: even with virtual nodes, the load distribution is uneven. Some shards get 20% more traffic than others because hash rings produce clumpy arcs. Google's Maglev load balancer solved this with a different approach: build a lookup table where every backend appears almost exactly the same number of times.

How it works. You pick a table size M (a prime number, typically 65,537 or larger). For each backend b, you generate a permutation of the numbers 0 to M-1 using two hash functions:

• offset(b) = h1(b) mod M
• skip(b) = (h2(b) mod (M-1)) + 1
• permutation(b, j) = (offset + j × skip) mod M

Then you fill the lookup table one slot at a time by round-robin over backends. Each backend proposes its next preferred slot from its permutation; if that slot is taken, it tries the next one in its permutation. Continue until every slot is filled. To route a request, hash the key, take it mod M, and look up the backend.

Why this beats ring hashing. With N backends, each backend owns almost exactly M/N slots — the maximum imbalance is a single slot. Compare that to ring hashing with 100 virtual nodes per backend, which typically has ±5% imbalance and can spike to ±20% with few backends.

The disruption trade-off. When a backend fails, ring hashing reassigns only that backend's keys to neighbors on the ring — very minimal disruption. Maglev's guarantee is weaker: roughly 1/N of keys move to different backends, but the table rebuild can shuffle unrelated keys too. In practice, Google measured that removing one backend from a 1000-backend pool moves only ~1.6% of connections (vs the ideal 0.1%). For stateless load balancing where connection tracking handles in-flight requests, this is acceptable.

Real-world example. Google's Maglev handles over a million packets per second per machine. YouTube video requests hit Maglev before reaching the backend fleet; the lookup table is small enough to fit in L1 cache, making per-packet routing decisions cost only a few nanoseconds. Envoy proxy also implements Maglev as a load balancing option specifically for this uniformity property.

Rule of thumb. Pick M ≥ 100 × N where N is your expected backend count. With M=65537 and N=100 backends, imbalance is under 0.02%. If N grows past M/100, either grow M or accept coarser distribution.