From Partition Key to Node — Hash Sharding Paths Diagram

Hashing the Key

A good hash turns skewed input into a uniform distribution; the same key always gives the same hash
Cryptographic strength is not needed: MongoDB uses MD5, Cassandra and ScyllaDB use Murmur3
Java Object.hashCode() and Ruby Object#hash vary between processes, so they are unsuitable for sharding
hash(key) % N looks easy, but when N changes almost every key moves to another node

Fixed Shards Versus Hash Ranges

A fixed count (1,000 shards over 10 nodes) keeps the key-to-shard map stable; only whole shards move when nodes change
More shards than nodes lets a powerful node take more shards; the count should divide many ways
If the count turns out wrong, an expensive resharding splits every shard and rewrites files
Hash ranges adapt like key ranges: split or merge as data grows, at the cost of rewriting data

When the Load Is Not Uniform

Uniform hashes do not guarantee uniform load: a hot key still lands on one shard
A range-based scheme can isolate a hot key on its own shard and machine
Random prefixes split writes across 100 keys, but reads must combine all of them
Cloud systems call the fix heat management or adaptive capacity (DynamoDB)