Range-based vs hash-based sharding trade-offs?

WHAT THIS TESTS This assesses whether you can match a sharding strategy to query patterns and anticipate hot spots, a practical scaling skill.

A GOOD ANSWER COVERS Range-based sharding assigns each shard a contiguous range of shard-key values, for example users A through F on one shard and G through M on another, or one shard per month of data. Its strength is range and ordered queries: a query for a key range or a time window touches only the relevant shards, and ordered scans are efficient. Its weakness is hot spots. If the shard key is monotonically increasing, like a timestamp or auto-increment id, all new writes land on the single shard holding the highest range, overloading it while others idle. Hash-based sharding applies a hash function to the shard key and uses the result to assign the row to a shard, scattering even sequential keys uniformly across all shards. This distributes load evenly and prevents write hot spots. Its weakness is that range queries become inefficient: since adjacent keys land on different shards, a range scan must fan out to every shard and merge results, and ordered access is lost.

COMMON WRONG ANSWERS Claiming hash sharding is always better, ignoring that it ruins range queries that many workloads depend on. Ignoring the monotonic-key hot spot, the classic range-sharding failure. Forgetting that range sharding rebalances more naturally by splitting ranges, while hash sharding makes resharding harder unless consistent hashing is used. Conflating the shard key choice with the strategy; a bad key hurts either approach.

LIKELY FOLLOW-UPS How does consistent hashing ease adding and removing shards? How would you shard time-series data to avoid a hot shard? What is a compound or composite shard key? How do you handle queries that do not include the shard key?

ONE CONCRETE EXAMPLE For an analytics table queried mostly by date range, range sharding by date makes time-window scans hit only a few shards, but ingesting today's data hammers one shard. For a user-profile store accessed by user id point lookups, hash sharding on user id spreads writes evenly with no hot spot, accepting that any rare cross-user range scan must query all shards.