What the ring changes

Consistent hashing places keys and servers in one hash space. A key is assigned to the first server encountered while walking the ring in a chosen direction. When membership changes, this can limit remapping compared with a fixed modulo scheme, where changing the divisor commonly changes assignments for most keys. There is no universal rule that exactly 1/N of keys move: the observed fraction depends on token placement, membership, weights, key distribution, and failure or recovery policy.

Virtual nodes and operational trade-offs

The Dynamo paper uses virtual nodes: one physical machine owns several positions on the ring. This can improve statistical balance and lets operators give machines different weights by assigning different numbers of tokens. More positions also increase ring metadata and can expand the work involved in movement and repair. They do not guarantee equal request cost. A uniform key count can still produce uneven CPU, network, or storage use when key popularity and per-key work are skewed.

Replication is a separate design

Dynamo combines ring ownership with replication to successor nodes and availability mechanisms, but the hashing rule alone does not provide replication, consensus, or strong consistency. Replication factor, read/write quorum, temporary handling during failures, and repair behavior are independent choices that depend on the data model and service goals. A cache still needs expiration and stampede controls; a durable store needs explicit replica synchronization and safe movement procedures.

Basic hashing can still overload nodes

Google Research scientists Vahab Mirrokni and Morteza Zadimoghaddam describe a limitation of basic consistent hashing: it reduces movement in dynamic assignments, yet its load balance can be no better than random assignment in the worst case. Their bounded-load algorithm adds a capacity constraint and is reported as having been deployed in Google Cloud Pub/Sub. This is a distinct algorithmic variant, not an automatic property of every hash ring. It introduces extra assignment rules and trades some flexibility in movement for a bound on server load.

How to evaluate it

Measure with production-like key popularity and request costs instead of inferring balance from server count alone. Test token counts, heterogeneous weights, node loss, repair bandwidth, and throttled rebalancing. The expert perspective here is the named Google researchers’ analysis and deployment report; it should not be read as a guarantee for other implementations or workloads.

References