Database Sharding
System Design: lesson 8 of 15
Split the data itself when one box is full.
Lesson 8 of 15 · 6 min
Database Sharding
Step 1 of 12
One database holds everything, and its writes no longer fit on one box.
The Idea
Sharding splits one dataset across several databases by a shard key. Each shard owns a slice and serves its own reads and writes, so write capacity finally scales out. Everything then hangs on that key: queries carrying it touch one shard, queries without it touch all of them.
Real-World Example
A national archive splits birth records across buildings by year of birth. Given a year, a clerk walks to one building. Ask for everyone with a particular surname and every building must be searched — and the buildings holding the baby-boom years are permanently the busiest.
The Tradeoff
Cross-shard joins, unique constraints and transactions get hard or vanish, and a poorly chosen key leaves one hot shard doing all the work while the rest idle. Resharding a live system is a migration project, so shard only after replication and caching are genuinely exhausted.
Your turn
Put the steps in the right order.
- Route each query to the shard that owns its key
- Pick a shard key that appears in nearly every query
- Watch for a hot shard and reshard before it saturates
- Map key ranges or hash buckets onto physical databases
Mini quiz
1 / 3