Tools: New You Sharded Your Database. Now One Shard Is On Fire 2026
Split the database into 16 shards. Distributed users evenly by user_id hash. Each shard handles 6.25% of traffic. Perfect balance.
One celebrity with 50 million followers posted about your product. All 50 million followers have user IDs that hash to... shard 7.
Shard 7 is now handling 80% of your traffic. The other 15 shards are idle. Shard 7 is melting.
Uniform distribution. Simple logic. What could go wrong?
Everything. Because real-world access patterns don't care about your hash function.
A viral post from one user means millions of reads on that user's shard. Followers are distributed across shards, but the content they're accessing isn't.
Users who signed up on the same day often have sequential IDs. They also often have similar usage patterns. Your "random" distribution isn't random at all.
Morning in Tokyo means heavy traffic from Japanese users. If your sharding key correlates with geography, one shard gets hammered while others sleep.
Log the most frequently accessed keys per shard. The top 1% of keys often cause 50% of load.
For keys you know will be hot, add a random suffix:
Source: Dev.to
