What are the Main Database Sharding Strategies?

Compare range, hash, and directory-based sharding strategies, their trade-offs, hotspot risks, and when to use each.

hardQ140 of 224 in System Design Est. time: 6 minsLast updated: July 2026

Expected Interview Answer

The main sharding strategies are range-based (splitting data by contiguous key ranges), hash-based (splitting data by a hash of the key), and directory-based (looking up shard ownership in a mapping service), each trading off query efficiency, rebalance cost, and hotspot risk differently.

Range sharding stores contiguous key ranges on the same shard, which makes range queries (like a date range scan) fast because the data is physically co-located, but it risks hotspots when writes cluster around one range, such as monotonically increasing IDs or timestamps all landing on the newest shard. Hash sharding applies a hash function to the shard key and distributes rows evenly, which solves the hotspot problem for writes but destroys locality, so a range query has to fan out to every shard. Directory-based sharding keeps an explicit lookup table mapping each key (or key range) to a shard, giving maximum flexibility to move individual tenants or rebalance unevenly loaded shards, at the cost of an extra lookup hop and a potential single point of failure in the directory service itself. Real systems often combine approaches, for example hashing a composite key (tenant_id, entity_id) so a single tenant’s rows stay together while tenants are spread evenly across shards.

Range sharding preserves locality for efficient range scans and ordered queries
Hash sharding spreads write load evenly and avoids hotspots on sequential keys
Directory-based sharding allows fine-grained, flexible rebalancing per key or tenant
Composite shard keys can combine the strengths of range and hash approaches

AI Mentor Explanation

Range sharding is like seating spectators by the exact over they arrived in, so a steward covering overs 1 to 10 can answer any question about that block instantly, but if everyone rushes in during the last over before a big finish, that one steward’s section gets overloaded. Hash sharding is like assigning every spectator a seat based on a scrambled ticket number, spreading the crowd evenly across all stewards regardless of when they arrived, though now answering a question about overs 1 to 10 means checking with every steward. Directory-based sharding is like a stadium office keeping a master seating chart that can move any individual fan to any section on demand. Each approach balances even distribution against how easily you can query a contiguous slice of the data.

Step-by-Step Explanation

Step 1
Pick a shard key
Choose a column (or composite of columns) with high cardinality and even access patterns to determine how rows are distributed.
Step 2
Choose the partitioning function
Range partitions by contiguous key values, hash partitions by a hash of the key, directory-based looks up ownership in a mapping table.
Step 3
Route reads and writes
The application or a routing layer computes which shard owns a given key and sends the query there directly.
Step 4
Plan for rebalancing
Design the shard count and key function so that adding capacity later moves only a small fraction of existing data.

What Interviewer Expects

Names and correctly contrasts range, hash, and directory-based sharding
Identifies the hotspot risk of range sharding on sequential/monotonic keys
Recognizes hash sharding sacrifices range-query locality for even distribution
Mentions composite shard keys or consistent hashing as practical refinements

Common Mistakes

Treating sharding as a single monolithic strategy instead of a family of trade-offs
Choosing a low-cardinality shard key that creates uneven, oversized shards
Ignoring that hash sharding makes range queries expensive fan-outs
Not discussing how the chosen strategy affects future rebalancing cost

Best Answer (HR Friendly)

“Sharding strategies decide how you split one big dataset across many smaller databases. Range sharding keeps related data together by splitting on value ranges, which is great for range queries but can overload one shard with too much recent activity. Hash sharding spreads data evenly using a hash function, which avoids hotspots but makes range queries slower. Directory-based sharding uses a lookup table so you can move individual pieces of data around flexibly. Most production systems pick a hybrid based on their actual query patterns.”

Code Example

Hash vs range shard routing (pseudo-code)

NUM_SHARDS = 8

def hash_shard(key: str) -> int:
    # even distribution, no locality for range scans
    return hash(key) % NUM_SHARDS

def range_shard(user_id: int, boundaries: list[int]) -> int:
    # boundaries e.g. [1000, 2000, 3000, ...], keeps contiguous ids together
    for i, upper in enumerate(boundaries):
        if user_id < upper:
            return i
    return len(boundaries)

def directory_shard(tenant_id: str, directory: dict[str, int]) -> int:
    # explicit mapping, supports moving a single tenant independently
    return directory[tenant_id]

Follow-up Questions

How would you pick a shard key for a multi-tenant SaaS product?
What happens to a hash-sharded system when you need to add more shards?
When would directory-based sharding be preferable despite the extra lookup hop?
How does consistent hashing reduce the rebalancing cost of hash sharding?

MCQ Practice

1. Which sharding strategy is most prone to write hotspots with monotonically increasing keys?

2. What is the main downside of hash-based sharding for query patterns?

3. What is the defining feature of directory-based sharding?

Flash Cards

1 / 4

What are the Main Database Sharding Strategies?

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Pick a shard key

Choose the partitioning function

Route reads and writes

Plan for rebalancing