When you have 4 nodes, how do you decide which node stores user #1052? If you just put it on a random node, you'd have to broadcast every read query to all 4 nodes to find it. That doesn't scale.
Instead, we use a deterministic routing algorithm. The simplest algorithm is Modulo Arithmetic.
Modulo hashing is perfectly balanced, incredibly fast, and very easy to implement. But it has one fatal flaw: it is completely inflexible when the cluster size changes.
Watch what happens when we try to add a 4th node to handle more traffic. When N changes from 3 to 4, the math changes. Suddenly, 1052 % 4 = 0. The data is still sitting on Node 2, but all new read requests are sent to Node 0. To fix this, you have to move the data.
1. Click "Write Data" to distribute 12 keys cleanly across 3 nodes using modulo math.
2. Then, click "Add Node 4" to see the catastrophic impact on data locality.
When you added Node 4, nearly every single piece of data had to be moved to a new server to satisfy the new modulo math. If your database had 1 Terabyte of data, adding a single node would cause 750 Gigabytes of data to migrate across the network simultaneously, completely melting the cluster and taking the application offline.
Because of this, no serious modern database uses plain Modulo Hashing. We need a system where adding 1 node only forces a tiny fraction of the data to move. We need Consistent Hashing.