# Consistent hashing vs Rendezvous hashing

> Choose ring-based consistent hashing when a large node set makes per-request placement cost important; choose rendezvous hashing when simpler placement and replica ranking matter more than scanning all candidate nodes. Both limit remapping when membership changes, and rendezvous hashing is itself part of the broader family of consistent hashing techniques.

Source: https://sysround.com/compare/consistent-hashing-vs-rendezvous-hashing
Updated: 2026-11-05


## Side by side

| | Consistent hashing | Rendezvous hashing |
|---|---|---|
| Placement rule | Hash the key; find its successor on a token ring | Score each key-node pair; highest score wins |
| Standard lookup cost | O(log(NV)) with a sorted token array | O(N) for a full candidate scan |
| Placement metadata | O(NV) tokens for N nodes and V virtual nodes each | O(N) node identities and optional weights |
| Balance | Depends on token placement and virtual-node count | Uniform hashes give equal expected ownership |
| Membership changes | Moves keys in affected token ranges | Moves keys whose winning node changes |
| Capacity weighting | Allocate more tokens or controlled ranges | Use a weighted rendezvous scoring formula |
| Replica selection | Walk the ring, skipping duplicate physical nodes | Take the highest-ranked distinct nodes |
| Operational requirements | Consistent membership, token map, and migration protocol | Consistent membership, scoring, and migration protocol |

## The differences that matter

The main algorithmic trade-off is lookup work versus placement metadata. A conventional ring hashes a key once and binary-searches a sorted token array. Basic rendezvous hashing computes a score for every eligible node, but needs no virtual-node ring. Cached placements or hierarchical variants can change these costs, so name the implementation you are comparing.

Balance comes from different mechanisms. A ring with one randomly placed token per node can have uneven ownership; virtual nodes reduce that variance. Rendezvous hashing gives each equal-weight node the same expected share without virtual nodes. Neither guarantees equal request volume, byte usage, or CPU load when keys differ in popularity or size.

Both avoid the widespread reshuffling caused by hash(key) modulo node count. With equal-weight rendezvous hashing, adding a node to N existing nodes moves an expected 1/(N+1) of keys. A ring moves the ranges assigned to the new node, whose total size depends on token placement. Neither algorithm copies data or makes the ownership transition safe.

Rendezvous hashing directly produces a preference ranking for replicas and fallback nodes. A ring finds successors, skipping tokens belonging to physical nodes already selected. Both need additional rules for rack or zone diversity, and both need explicit behavior when clients disagree about membership or a node is temporarily unreachable.

## Choose Consistent hashing when

- The candidate node set is large and placement runs on every request, making a full rendezvous scan unattractive.
- The storage design already uses token ranges for streaming, repair, and ownership reporting.
- You need adjustable capacity shares through token allocation and can manage the extra placement metadata.
- Your existing routing layer distributes versioned ring maps and supports controlled range migrations.

## Choose Rendezvous hashing when

- The candidate pool is small enough that scoring every node fits the routing CPU budget.
- You want deterministic placement without choosing and maintaining virtual-node counts.
- You need a stable ordered list of preferred owners for replicas or fallback routing.
- Independent routers can share stable node identities, membership versions, and an identical scoring implementation.

## Worked example: Choosing placement for a growing cache

Suppose a cache has 100 equal-capacity nodes and handles 1 million lookups per second through routers. Basic rendezvous hashing evaluates 100 million key-node scores per second across those routers; whether that fits depends on the hash function and CPU budget. A ring with 160 virtual nodes per physical node stores 16,000 tokens and uses binary search for placement. Adding a 101st node moves an expected 1/101 of keys under equal-weight rendezvous hashing; ring movement depends on the new token ranges. For either design, plan for cache misses during warmup and protect the backing store. Choose based on measured routing cost and operational fit, not remapping alone.

## In the interview

- Clarify terminology first: compare a token-ring implementation with highest-random-weight, or rendezvous, hashing rather than claiming only the ring provides consistent placement.
- State node count, request rate, and where routing executes. Expect the interviewer to ask whether O(N) scoring is affordable or whether placements can be cached.
- Separate placement from migration. Explain how a new owner receives existing data, how writes are handled during transfer, and when the old owner stops serving.
- Describe membership distribution and failure handling. A timeout should not silently create conflicting ownership decisions across routers.
- Explain replica diversity and hot-key handling separately. Stable key placement does not prevent one popular key from overloading its owner.

## Common mistakes

- Claiming rendezvous hashing is unrelated to consistent hashing, rather than distinguishing it from the familiar ring implementation.
- Calling ring lookup O(1) without specifying a lookup table or another implementation that provides it.
- Assuming balanced key counts mean balanced traffic, storage, or CPU consumption.
- Treating automatic remapping as safe data migration, or treating the next-ranked replica as automatically up to date.

## Interview questions where it comes up

- [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): The choice affects cache ownership, routing cost, replica selection, and miss bursts when membership changes.
- [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Partition placement must work alongside replica diversity, ownership migration, and consistent membership views.
- [Design a distributed rate limiter](https://sysround.com/questions/design-rate-limiter): Routing each account or API key to a stable state owner requires explaining what happens to counters during failover or rebalancing.

## FAQ

### Is rendezvous hashing a type of consistent hashing?

Yes, in the broader sense: it provides stable key placement with limited remapping when nodes join or leave. In comparisons, “consistent hashing” usually means the token-ring algorithm. State that distinction so the discussion is about implementations rather than terminology.

### Which is faster, consistent hashing or rendezvous hashing?

A sorted-token ring uses O(log(NV)) lookup work, while basic rendezvous hashing scores all N candidate nodes. That usually makes the ring more attractive as the candidate set grows, but actual latency depends on hashing cost, memory access, caching, and implementation. Benchmark the routing path under your expected workload.

### Do consistent hashing and rendezvous hashing solve hot keys?

No. Both usually assign a key to one primary owner, so a popular key can still overwhelm that node. Replicated reads, local caching, request coalescing, or application-specific key splitting address that problem separately.

## Related concepts

- [Consistent hashing](https://sysround.com/concepts/consistent-hashing)
- [Database sharding](https://sysround.com/concepts/database-sharding)
- [Load balancing](https://sysround.com/concepts/load-balancing)
- [Database replication](https://sysround.com/concepts/replication)
- [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.