Sharding (Hash-Based Key Routing)

Picture a huge pile of mail. Instead of one overflowing mailbox, you sort it into 4 mailboxes. Sharding does the same thing to your database. Instead of one giant table holding every user, you split it into several smaller tables called shards. Each user's data lives in exactly one shard. To pick the right shard for a piece of data, you turn its key (like a user ID) into a number. You use that number to pick a shard. The same key always lands in the same shard.

1. 1Pick a number of shards, N — for example, 4 database instances.
2. 2For any key, like a user ID, compute a hash number from it. The same key always produces the same number.
3. 3Take the hash mod N. That remainder — a number from 0 to N-1 — tells you exactly which shard owns that key.

Use sharding when one database server can no longer hold all your data or handle all your traffic. You split the data across several servers, so each one deals with only a fraction of it.

• ⚠Picking a shard count and then changing it casually. As this example shows, going from 4 shards to 5 moves most keys to a different shard. That means a painful data migration.
• ⚠Sharding by a key that isn't evenly spread out — for example, by signup date, when most users signed up in one week. This creates a 'hot shard' that gets overloaded while the others sit idle.