Rendezvous hashing vs consistent hashing vs mod N: an interactive comparison

When keys are spread over servers and servers come and go, the placement rule decides how many keys have to move. hash(key) mod N moves almost all of them. A consistent hashing ring moves only the necessary share but needs many virtual nodes to stay balanced. Rendezvous hashing, also called highest random weight, gets both with a simpler rule: every server scores the key with a hash, and the highest score wins.

The playground places 1,200 keys on six servers three ways. Remove a server or add one, change the ring’s virtual nodes, and compare how many keys move and how even the load stays.

Why mod N fails and the ring needs help

With mod N, changing N from 6 to 5 changes the answer for about 83% of keys, when only server 3’s sixth needed to move. Caches go cold and databases reshuffle almost everything. A consistent hashing ring moves only the keys between the changed point and its predecessor, but with one point per server the gaps are uneven: before anything changes, one server already holds 2.4 times its share; when server 3 leaves, all of its keys fall to a single neighbour; a newly added server can catch just one key. Giving each server 100 virtual points evens this out, at the cost of a table of 600 points to store and search.

How rendezvous hashing works

For each key, compute hash(key, server) for every server and pick the largest. Each server’s score is independent, so removing server 3 only changes the answer for keys where server 3 had the top score, 17.5% here, and those keys go to whichever server had the second-highest score, which is effectively random: the load spreads evenly over the remaining five. Adding a server takes an even slice from every existing one. No virtual nodes, no ring to maintain, and taking the top few scores gives a natural list of replicas.

The cost is lookup work: N hashes per key instead of one hash and a binary search. With tens of servers that is nothing; with thousands, use a hierarchy (pick a group, then a server within it) or a ring. Weighted variants handle servers of different sizes. Rendezvous hashing is used in CDN and proxy routing, for example to decide which cache server holds an object, and in systems such as Apache Ignite.

Rendezvous hashing in code

import hashlib

def score(key: str, server: str) -> int:
    return int.from_bytes(hashlib.blake2b(f"{key}|{server}".encode(), digest_size=8).digest(), "big")

def owner(key: str, servers: list[str]) -> str:
    """Rendezvous (highest random weight) hashing: every server scores the key, the highest wins."""
    return max(servers, key=lambda s: score(key, s))

def owners(key: str, servers: list[str], replicas: int = 3) -> list[str]:
    """Replicas come for free: take the top few scores."""
    return sorted(servers, key=lambda s: score(key, s), reverse=True)[:replicas]

In a system design interview

When you shard a cache or route requests to stateful nodes, name the rule: “Each edge proxy maps a URL to one of the 40 cache servers in its region with rendezvous hashing, so all proxies agree without coordination, and when a server fails only its objects move, spread evenly over the rest. With 40 servers the 40 hashes per request are negligible.” Expect the follow-ups: what happens to hot keys, how membership changes reach every proxy, and when you would choose a ring instead.

Read the guide to consistent hashing or sharding and partitioning, see hot keys, or watch a strong candidate design a distributed cache.

Questions people ask