The Core Idea
Splitting Data Horizontally Across Machines
Sharding is a form of horizontal scaling: instead of storing your entire dataset on one increasingly large (and increasingly expensive, and eventually physically limited) machine, you split the data itself into pieces called shards, with each shard living on a separate machine. A query for a specific piece of data gets routed to whichever shard actually holds it, and the overall system behaves as one logical database even though the data is physically spread across many machines.
This is different from simple read replication (copying the SAME full dataset to multiple machines to spread out read load) — sharding splits the data itself, so each shard machine holds only a PORTION of the total data, which is what allows the total dataset size and write throughput to scale beyond what any single machine could handle.
💡 Memory Trick
Think of a massive library that's outgrown a single building. Instead of trying to cram every book into one increasingly overcrowded building (vertical scaling, hitting a physical ceiling), the library system opens several branch locations, each holding a specific portion of the total collection — Branch A holds fiction A through F, Branch B holds fiction G through M, and so on. A librarian directory tells patrons which specific branch to visit for a specific book, and the overall library system as a whole can keep growing by adding new branches.
The Sharding Strategies
How to Decide Which Shard Holds What
1
Range-Based Sharding
Data is split based on ranges of a chosen key — like customer IDs 1-1,000,000 on shard A, 1,000,001-2,000,000 on shard B. Simple to reason about and supports efficient range queries, but can lead to uneven load if data isn't distributed evenly across the chosen ranges (a common problem: recently-created records often cluster on whichever shard holds the highest current range, overloading that one shard).
2
Hash-Based Sharding
A hash function is applied to the shard key, and the result determines which shard the data lives on — similar in spirit to how a hash table distributes keys across buckets. This tends to distribute data much more evenly across shards than range-based sharding, but makes range queries (like 'all customers with ID between X and Y') inefficient, since matching records could be scattered across every shard.
3
Directory-Based Sharding
A separate lookup service (the 'directory') explicitly tracks which shard holds which piece of data, rather than deriving the answer purely from a range or hash formula. This offers the most flexibility (shards can be rebalanced by simply updating directory entries) but introduces the lookup service itself as a new, critical piece of infrastructure that must be fast and highly available.
The Real Challenge
Choosing the Shard Key
The single most important, hardest-to-change decision in sharding is choosing the shard key — the column (or combination of columns) used to decide which shard a given piece of data belongs to. A poorly chosen shard key can lead to 'hot shards' (one shard receiving disproportionately more traffic or data than others, defeating the purpose of spreading load) or force expensive cross-shard queries whenever you need data that's scattered across multiple shards rather than concentrated on one.
Sharding also introduces real complexity beyond the initial split: cross-shard JOINs become expensive or impossible to do efficiently, maintaining strong ACID transaction guarantees ACROSS multiple shards is significantly harder than within a single database, and resharding (redistributing data when you add more shards later) is a genuinely difficult operational task. For these reasons, sharding is typically adopted only once a single well-optimized machine (with proper indexing and possibly read replicas) genuinely can't handle the load anymore — not as a default starting architecture.
🖥️ Applied Scenario
Your application's single database server is struggling under write load from millions of active users, and you're designing a sharding strategy based on user_id.
1
You initially consider range-based sharding by user_id (users 1 to 1 million on shard A, and so on), but recognize that new user signups will always land on the highest-numbered shard, overloading it with disproportionate write traffic while older shards sit relatively idle.
2
You switch to hash-based sharding on user_id instead, which spreads new signups evenly across all shards regardless of signup order, avoiding the hot-shard problem range-based sharding created.
3
You verify that your application's most common queries (looking up a specific user's data by their user_id) work efficiently under hash-based sharding, since the hash function deterministically identifies exactly which single shard to query.
4
Conclusion: you accept that hash-based sharding makes a query like 'find all users created this week' inefficient (since matching users are now scattered across every shard) — an acceptable trade-off, since your application's actual dominant query pattern is single-user lookups, not range scans by signup date.
📌 Exam Application
Exam questions frequently ask you to compare range-based, hash-based, and directory-based sharding strategies, expecting you to reference their specific trade-offs around data distribution evenness and range-query efficiency. You may also be asked to identify what makes a good or poor shard key choice given a described application's access patterns, and to explain why cross-shard operations (joins, transactions) are more difficult than their single-database equivalents.
⚠️ Most Common Database Sharding Mistakes
The most common mistake is choosing a shard key based on convenience (like an auto-incrementing ID) without considering the actual query and write patterns — this frequently leads to 'hot shards' where recent or popular data disproportionately overloads one shard, largely negating the benefit sharding was meant to provide. Another frequent error is treating sharding as a first-resort scaling solution — sharding introduces substantial operational complexity (harder transactions, harder joins, harder rebalancing), so it's normally adopted only after simpler techniques (proper indexing, query optimization, read replicas, vertical scaling) have already been exhausted for the specific workload.
✓ Quick Self-Test
Can you explain the trade-off between range-based and hash-based sharding in terms of data distribution evenness versus range-query efficiency? Given a described application's access patterns, can you identify whether a proposed shard key would risk creating a hot shard, and explain why?
→
← All Databases Lessons