Why modulo placement becomes expensive
A hash function can assign a key to a server. But a placement scheme is only useful if we also understand what happens when the server set changes.
The simplest scheme is hash(key) % nodeCount. It is easy to implement, but changing the divisor can change ownership for many keys. Consistent hashing asks a different question: can membership changes affect a more localized part of the keyspace?
Place keys on a ring
- Hash the key
- Locate its position
- Walk clockwise
- Choose the next token
- Resolve physical owner
Hash both keys and node identifiers into the same bounded space. For each key, walk clockwise to the next node position. That node owns the key. If there is no later position, wrap to the first node.
owner(key) = first node with position >= hash(key)
or the first node after wrappingThe lab uses a deterministic 32-bit hash for visualization. It is not a cryptographic primitive or an adversarial routing defense.
Membership changes and replica semantics
Remove one node
When a node disappears, the keys it owned move clockwise to its successor. Keys assigned to the remaining nodes keep their owners.
This local movement is the property to observe in the lab. It does not imply perfect balance. A single token per physical node can create very uneven segments.
Virtual nodes give each physical node several positions. They can improve distribution and make movement more granular, although the actual balance still depends on token placement and workload. The lab exposes a virtual-node count so this is visible rather than asserted.
Placement is not replication
A ring answers where a key should live. It does not make a copy durable, synchronize replicas, elect a leader, or restore a failed process.
The neighboring replication experiment models those concerns separately. A write advances the primary’s version; secondaries learn it on later logical ticks. Reading a lagging secondary can return an older version.
Quorum arithmetic has conditions
With a fixed replica set of size N, a successful write acknowledged by W replicas and a read that consults R replicas must intersect if R + W > N.
Intersection alone is not a complete linearizability protocol. Version ordering, concurrent writes, failures during acknowledgment, and membership changes still matter. The teaching model uses one writer, a fixed replica set, explicit versions, and no concurrent operations.
In that restricted model, changing R and W helps explain why stronger overlap can reduce the number of failures an operation tolerates. It does not justify blanket consistency claims about real systems.
Remove a node in the interactive example
Open the Distributed Systems Playground. Record the key distribution, fail a node, and inspect how many keys moved. Reset, then explore replication lag before changing the read quorum.
All decisions are reproducible from the same initial state and action sequence. Wall-clock time controls playback speed only; it is not part of the simulation state.
Count moved keys before timing the algorithm
Record keys per owner before the failure, the number of changed owners, and the post-failure distribution. These are deterministic simulation counts, not bytes transferred by a real cache.
The local microbenchmark separately times this site’s ring construction and key placement. Its percentiles summarize batch averages. It does not measure network rebalancing, cache-miss penalties, or a C++ cluster.
Balance is more than an equal key count
More virtual nodes add bookkeeping and can improve distribution, but do not guarantee an even workload. Hot keys and unequal request sizes can dominate an apparently balanced key count.
Failure detection, membership agreement, repair, and durable replication are separate problems. A browser ring cannot demonstrate that those problems have been solved in a production service.
A production rebalance also needs a transition protocol. If the new owner starts serving before data has moved, reads may miss; if two routers disagree about membership, writes may go to different owners. A design can copy data before switching traffic, forward requests temporarily, or use versioned routing tables, but each choice needs a defined failure path.
The ring does not tell you when it is safe to delete the old copy. Treat “the mapping changed” and “the data migration completed” as separate events in both implementation and observability.
Further reading
Primary references behind this explanation. Consult documentation for the version and environment you actually run.