Consistent Hashing Lifecycle Visualization

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. The scheme’s main advantage is minimal data movement: when a node joins or leaves, only the keys in that node’s adjacent ring segment move, not the whole table.

For parameter experimentation, the Consistent Hashing Simulator is also available.

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.

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 calculations transforming IDs into 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 ring circle displaying all nodes and tokens.

Cache Nodes (Node A, Node B, Node C)

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, watch nodes changing states (healthy/crashed) and caching data.

Key Token & Clockwise Lookup

This component exists to resolve lookups deterministically. It positions keys on the ring and searches clockwise until finding the next active node. In the demo, observe a token landing on the ring and looking clockwise to Node A.

Virtual Nodes

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, observe the ring getting split into smaller, interleaved segments.

Failure Remap

This component exists to handle node crashes gracefully without losing cache records of other healthy nodes. It redirects request hashes from the failed node to the next clockwise neighbor on the ring. In the demo, watch keys shifting clockwise to live nodes when Node A crashes.

Hotspot Detector & Balanced Ring

This component exists to distribute keys evenly and prevent individual nodes from getting overloaded. It monitors segment sizes for skew and adjusts virtual node locations to rebalance the keyspace. In the demo, observe hotspot indicators highlighting large gaps and the ring rebalancing itself.

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.