Sharding sounds like a clean solution until you encounter its most feared operational challenge: Resharding — the process of changing the number of shards in a live system.
Why Resharding Is Painful
Imagine you have 4 shards using hash sharding (hash(user_id) % 4). Your data grows, and you need to expand to 8 shards (hash(user_id) % 8).
With 4 shards, User ID 7 lands on Shard 3 (7 % 4 = 3).
With 8 shards, User ID 7 must land on Shard 7 (7 % 8 = 7).
Almost every single row in your database is now on the wrong shard. You must physically move the majority of your data between live servers while your application continues to read and write. During the migration, a query might write to the old location and read from the new one (or vice versa), producing corrupted or missing results. This is an extraordinarily complex, risky, and slow operation.
Consistent Hashing: A Partial Mitigation
Consistent Hashing is a technique that reduces the resharding problem. Instead of hash(key) % N, you map both keys and shards onto a circular "hash ring." When you add a new shard, only the keys that fall between the new shard and its predecessor on the ring need to move — typically 1/N of the total data, not nearly all of it.
Traditional hashing (4→5 shards): ~80% of data moves
Consistent hashing (4→5 shards): ~20% of data moves
Consistent hashing is used by distributed systems like Apache Cassandra and many distributed caches. It doesn't eliminate resharding pain, but it makes it manageable.
The Operational Lesson
Because resharding is so painful, shard count should be chosen conservatively large upfront — it's easier to have 16 lightly-loaded shards than to reshard from 4 to 16 later. More importantly, sharding should always be a last resort after all other optimizations (caching, query tuning, read replicas, vertical scaling) are exhausted.