Splitting data across servers.
WHAT IT MEANS
Dividing a dataset across several databases, each holding part.
WHY IT IS DONE
When one server cannot handle the write volume or data size.
WHAT IT IS NOT
A first response to slowness.
WHY
Indexing, caching and replicas solve almost everything before this.
WHAT A SHARD KEY IS
The value determining which server holds a row.
WHY CHOOSING IT IS THE HARDEST DECISION
It is extremely difficult to change afterwards.
WHAT MAKES A GOOD KEY
Even distribution Queries usually touching one shard Related data landing together
WHAT MAKES A POOR ONE
Concentration on one shard Queries needing every shard
WHAT BREAKS UNDER SHARDING
Joins across shards Transactions spanning shards Unique constraints across the whole dataset Aggregate queries
WHAT THAT COSTS
Application complexity, permanently.
WHAT TO CONSIDER FIRST
Whether a natural boundary exists, such as customer or tenant.
WHY THAT HELPS
Queries stay within one shard naturally.
WHAT TO PLAN BEFORE STARTING
How shards are added later, and how data is rebalanced.
WHAT TO AVOID
Sharding by something that grows unevenly.
WHAT TO PREFER IF POSSIBLE
Not sharding.
