Sharding Strategies
Hash-based, range-based, and directory-based sharding — three ways to decide which shard a row actually lives on.
Overview
Building on the basic idea of sharding introduced earlier in this journey, there are three standard ways to actually decide which shard a given piece of data lives on — hash-based, range-based, and directory-based — each with different trade-offs for query patterns and, critically, for how hard resharding is later.
Why It Exists
The earlier chapter on relational database scaling established why you shard. This one covers how you decide where each row actually goes, because that single decision determines whether your shards stay balanced, whether range queries stay efficient, and how painful it is to add or remove shards down the line.
Real World Example
A hash-based scheme routes each row by hashing its key (e.g. `user_id`) — this spreads load evenly but scatters related rows, making a range query like 'all orders between two dates' expensive since matching rows are spread across every shard. A range-based scheme keeps keys in contiguous ranges per shard (shard 1 = users A-M, shard 2 = N-Z) — range queries within one shard are fast, but uneven key distribution can create unbalanced shards. A directory-based scheme keeps an explicit lookup table mapping each key or range to its shard — the most flexible for rebalancing, but that lookup table itself becomes a critical, must-scale piece of infrastructure.
Three Ways to Decide Where a Row Lives
Hash-Based Sharding
Routes each key through a hash function to pick a shard. Spreads load very evenly, but scatters related keys, making range queries expensive since they have to fan out across every shard.
Range-Based Sharding
Assigns contiguous key ranges to each shard. Range queries within one shard are fast, but uneven real-world key distribution — or a monotonically increasing key — can leave some shards far busier than others.
Directory-Based Sharding
Keeps an explicit lookup table mapping keys (or key ranges) to shards. The most flexible for rebalancing, since moving a key just means updating the directory — but the directory itself becomes a critical piece of infrastructure that must stay fast and available.
Why Resharding Is Hard
Rebalancing means physically migrating data between shards with minimal downtime — a genuinely expensive, high-risk operation under any scheme, though directory-based and consistent-hashing-based schemes make it noticeably less painful than a fixed hash-mod-N scheme.
Diagram
A write with a given key, routed three different ways
Hash-Based
hash(key) → shard, evenly spread
Range-Based
key falls into a contiguous range
Directory-Based
lookup table consulted for this key
Common Mistakes
Choosing hash-based sharding for a workload dominated by range queries
Why: Hash-based sharding deliberately scatters related keys across shards for even load — exactly the wrong property for 'give me all rows between X and Y' queries, which now have to fan out to every shard.
Fix: Choose range-based (or a hybrid) sharding scheme when range queries are the dominant access pattern.
Using range-based sharding with a monotonically increasing key, like an auto-incrementing ID or a timestamp
Why: All new writes land on the single shard holding the current highest range, creating a hot shard that absorbs all write traffic while every other shard sits idle.
Fix: Use a hash-based scheme, or a range scheme built on a key that isn't monotonically increasing, when write distribution matters more than range-query locality.
Underestimating the operational cost of resharding
Why: Rebalancing — whether adding a shard or fixing a hot spot — means physically migrating potentially huge amounts of data with minimal downtime, which is never free regardless of scheme.
Fix: Plan the sharding scheme with growth in mind from the start; consider consistent hashing specifically because it minimizes how much data moves when nodes are added or removed.
Interview Questions
What's the practical difference between hash-based and range-based sharding?
Hash-based sharding routes each key through a hash function, spreading data evenly but scattering related keys across shards. Range-based sharding keeps contiguous key ranges together on the same shard, which favors range queries but risks uneven load if the key distribution isn't uniform.
Why does a monotonically increasing shard key create a hot shard under range-based sharding?
If the key always increases (an auto-incrementing ID, a timestamp), every new row falls into the range owned by whichever shard currently holds the highest values — meaning all new writes concentrate on that one shard, while shards holding older ranges receive no new write traffic at all.
You need to add shards to a hash-based sharded system without a full data migration. What technique would help, and why?
Consistent hashing — the same technique covered in the wide-column stores chapter — maps keys onto a ring of nodes so that adding or removing a node only reassigns the fraction of keys near it on the ring, instead of reshuffling every key the way a simple hash-mod-N scheme would require when N changes.
Production Best Practices
Do
✓Choose the sharding scheme based on the dominant real query pattern (point lookups vs. range queries).
✓Avoid monotonically increasing keys as the basis for range-based sharding.
✓Use consistent hashing (or a directory-based scheme) specifically to make future resharding less painful.
Don't
✗Don't hash-shard a workload that's mostly range queries.
✗Don't range-shard on a key that only ever increases without checking for hot-shard risk.
✗Don't treat resharding as a cheap, low-risk operation under any scheme.
Comparison
| Load Distribution | Range Query Support | Resharding Difficulty | |
|---|---|---|---|
| Hash-Based | Even | Poor — fans out to every shard | Hard, unless consistent hashing is used |
| Range-Based | Risk of hot ranges | Excellent within a shard | Moderate — can split a range |
| Directory-Based | Flexible, depends on directory logic | Depends on directory design | Easiest — update the directory |