Sharding

When one database can't hold all your data or handle all your traffic, you split the rows across several machines. Each machine is a shard. The question sharding answers is simple to ask and easy to get wrong: given a row, which shard does it live on?

The common answer is to pick one column as the partition key, hash its value, and use the hash to choose a shard. Hashing turns any value into a number, and that number mod the shard count gives a shard. Same key value, same shard, every time. That is what lets you find a row later: hash the key, go straight to the shard, no searching.

The figure hashes each row's chosen key with a real hash function and places the row in hash mod n. Switch the partition key and watch the rows redistribute.

A good partition key has many distinct values, so the rows spread out. Pick the id column, where every row has a unique value, and the shards fill up fairly evenly. No shard is doing much more work than the others. That is the goal: even load.

A bad key has few distinct values, and the trouble is structural. Every row with the same key value hashes to the same shard, so a column with only a handful of values can only ever reach a handful of shards. Group by country, spread across seven values, and the load is uneven but livable. Group by plan, which is only free or pro, and it collapses: every row lands on one of at most two shards, one per plan value, however many shards you add. The rest can never receive a row. That overloaded shard is a hot shard, and it becomes the bottleneck for the whole system no matter how many machines you add. And an even-looking key can still mislead: many distinct values do not guarantee even load, because one celebrity key can hot-spot a single shard.

So the lesson is that adding shards does not help if your key can't spread rows across them. Choosing the key is the real decision.

This sets up the next problem. Hashing with mod n works until n changes. Add a shard and almost every row's hash mod n lands somewhere new, so nearly all your data has to move. The next topic, consistent hashing, is how systems avoid that.

The hash is a real FNV-1a hash and every placement is genuinely computed from it, not scripted. The dataset is tiny and hand-picked to show the range from even to hot in fourteen rows; real shards hold millions of rows and real systems use far more than three or four. The country values were chosen so their real hash spread reads as mild here, but the spreading itself is the honest output of the hash, not a staged result.

Hashing rows onto shards