Sharding, resharding, and quorums
Partitioning buys scale and takes away joins, uniqueness, and easy rebalancing.
What you will be able to do
- Choose a shard key that distributes load and matches the query
- Detect and fix a hot partition
- Explain resharding strategies that avoid downtime
- Compute quorum sizes for a desired consistency
The shard key decides everything
Sharding splits rows across nodes by a key. That key is in every request routing decision, so it must match how the application reads. Shard chat messages by channel id and a channel read hits one shard. Shard by message id and the same read fans out to all of them.
| Candidate key | Good for | Breaks when |
|---|---|---|
| User id | Per-user data, profiles, settings, personal feeds | A user with extreme activity; cross-user queries |
| Tenant id | SaaS isolation, per-tenant backups and limits | One tenant is orders of magnitude larger |
| Time | Events, logs, metrics; drop whole old shards | All writes hit the newest shard |
| Geo / region | Data residency, locality, regulatory boundaries | A region has a tiny or huge population |
| Hash of an id | Even spread, no natural ordering needed | Range queries across the hash |
user_id, but store messages with a sort key of (channel_id, message_id) so a channel's recent history is one contiguous range inside the user's shard. You keep locality at both levels without writing to every node.Hot partitions
Even sharding still concentrates load if one key is popular: a celebrity's post, a flash sale on one product, a tenant with a hundred times the traffic. Replication of that partition to several nodes spreads reads, but every write still lands on one leader.
- Salt the key — split one logical key into N sub-shards (
user_id#3), spreading writes at the cost of N reads to gather. - Dedicate capacity — move the big tenant to its own shard with its own quota; noisy-neighbour isolation beats clever hashing.
- Buffer the writes — accept the traffic into a queue and let one writer apply it in order, turning a burst into a smooth rate.
- Cache the read — the hot key is usually the hot read; a CDN or cache absorbs it without touching storage.
Resharding without downtime
Consistent hashing on a ring plus virtual nodes means adding a node moves only its share of keys, not a modulo reshuffle of everything. That is why it shows up in caches and shard maps, and why you mention it when asked how you would add capacity.
Quorums in one table
In a leaderless store with N replicas, a write acknowledged by W replicas and a read served by R replicas intersect if R + W > N. The intersection is what makes the freshest write visible.
| N | W | R | Property |
|---|---|---|---|
| 3 | 2 | 2 | Strong-ish: quorum reads and writes, tolerates one node down |
| 3 | 3 | 1 | Fast reads, brittle writes — a single failure blocks writes |
| 3 | 1 | 1 | Fast and available, but a read may miss a recent write |
| 5 | 3 | 3 | Tolerates two failures while keeping overlap |
Lower R + W also lowers latency and raises availability, because fewer nodes must answer. Say which you chose and what it costs: with W = 1 a write can be lost if that single node fails before replicating.
Worth remembering
- The shard key must appear in your hottest query, or every read fans out to every shard.
- Even distribution matters less than avoiding a single key that receives most traffic.
- Resharding must be incremental and reversible — dual writes plus backfill plus cutover.
- In a quorum store, R + W > N gives read-your-writes; smaller sums trade that for availability.