Database Sharding in 1 diagram and 204 words
Explained as simply as possible… but not simpler.
A technique that splits a large database into smaller, independent parts (shards) to distribute data across multiple servers.
As applications scale and databases grow, a single database server can become a bottleneck. Sharding helps scale horizontally by spreading data across multiple machines, improving performance and availability.
Use it when a single database cannot handle the read/write load or data volume.
You need to know
Shard key: Choosing the right shard key (e.g., user ID, region) affects data distribution and query efficiency. A bad choice can cause uneven load (a "hot shard").
Cross-shard operations are costly: Joins, transactions, or queries across shards are complex and slow - design to avoid them.
Rebalancing is hard: Moving data between shards when traffic grows unevenly or hardware changes is tricky and can require downtime or complex tooling.
Popular algorithms
Modulo-based Sharding – Data is assigned using
hash(key) % number_of_shards; simple but hard to scale (adding/removing shards reshuffles everything).Range-based Sharding – Shards are defined by value ranges (e.g., user_id 1–1000); good for predictable access but risks uneven load if data isn’t uniform.
Consistent Hashing – Maps data and shards to a ring; only a small portion of data moves when shards are added/removed.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️