Consistent Hashing Ring & Virtual Nodes

Mental Model

Consistent Hashing is a key distribution scheme where both servers and keys hash to the same circular range $[0, 2^{32}-1]$. Walking clockwise from a key’s hash position on the ring identifies the first server encountered, which owns that key. This decouples data layout from server counts and prevents global re-sharding during cluster scaling.

Components and Why They Exist

Client

This component exists to initiate request transactions, hash key values, and locate target database nodes. It computes key hashes, queries the hashing ring lookup table, and routes requests to the matching clockwise server. In the demo, watch request particles traveling from the client toward the ring.

Hash Function

This component exists to transform server IDs and keys into numeric points within a shared, circular keyspace. It converts key strings or server IP addresses into consistent integer positions on the hashing ring. In the demo, watch the mathematical conversion of IDs to position coordinates.

Hash Ring

This component exists to represent the range of hash values and establish logical boundaries of data ownership. It maps the positions of all virtual nodes clockwise and handles routing lookups based on nearest-node proximity. In the demo, observe the 360-degree circle with server points and key tokens.

Cache Servers (Physical Nodes)

Store data chunks locally to serve client read/write queries. Serves data matching the hashes mapped to its physical or virtual nodes. In the demo, notice that physical nodes receiving client read/write payloads at the bottom.

Virtual Nodes (Vnodes)

Prevents hotspots and uneven load distribution by scattering multiple identities for each physical node. Represents physical nodes at multiple locations on the ring, smoothing the average segment size. In the demo, notice that interleaved colored segments on the ring representing virtual node ranges.

Edge Cases and Misconceptions

Virtual Node Density

A common misconception is that a few virtual nodes are enough. In production, systems like Cassandra or Memcached often use 32 to 256 vnodes per physical node to achieve tight load balancing tolerances.

Cascading Failures on Crash

When a node crashes in a simple ring without vnodes, 100% of its load shifts directly to its single clockwise neighbor. If that neighbor gets overwhelmed and crashes, a cascading failure can wipe out the entire ring. Virtual nodes distribute the failed node’s keys across all remaining servers, preventing localized overloads.