LESSON 9.3
Sharding
Split data across many primaries when one can't hold it or keep up with its writes, and the costs that come with it.
6 min read
Caching and replicas scale reads. A bigger machine buys time. But when the writes or the data outgrow the largest primary you can run, you must split the data itself across several independent databases. Each piece is a shard (or partition), and each shard has its own primary and replicas.
Choosing a shard key
Everything depends on the shard key, the column that decides which shard a row lives on. A good one:
- spreads data and traffic evenly, with no celebrity or "today" hot spot;
- appears in the hot queries, so they touch one shard;
- keeps related data together, so a user's orders, payments and sessions share a shard and transactions stay local.
For most consumer apps that's the user or tenant id. For a chat app, the conversation id. For a marketplace, maybe the seller.
Range or hash
Range sharding
- Efficient range scans
- Easy to understand
- Hot spots for sequential keys like timestamps
- Manual split points
Pick it when: Keys that are naturally spread, and range queries matter.
Hash sharding
- Even spread
- No sequential hot spot
- Range queries hit every shard
Pick it when: The default for ids and point lookups.
Directory (lookup table)
- Move any tenant anywhere
- Isolate big customers
- The directory must be fast and highly available
Pick it when: Multi-tenant SaaS with very uneven tenants.
What sharding costs
- Cross-shard queries. Anything without the shard key must ask every shard and merge (scatter-gather). Keep those off hot paths or build a separate index or read model for them.
- Cross-shard transactions. A transfer between users on different shards can't be one local transaction. Use sagas or another pattern from module 20, or choose a key that keeps such data together.
- Rebalancing. Shards grow unevenly. Moving data while serving traffic is delicate; systems usually create many small logical shards up front (say 1,024) and move whole logical shards between machines.
- Global uniqueness. Auto-increment ids clash across shards. Use globally unique ids (UUIDs, Snowflake ids) or include the shard in the id.
Before you shard
Check the cheaper options first: query and index tuning, caching, read replicas, a bigger primary, archiving cold data, and splitting different features into separate databases (users in one, analytics events in another). Many large products run for years on those alone. When you do shard, managed systems (Vitess, Citus, CockroachDB, Spanner, DynamoDB) handle much of the routing and rebalancing for you.
Try it
Live Shard Rebalancing Service HLD
Move data between shards without downtime.