Sharding & Replication
Learn the difference between replication (copies of the same data, for availability and read scale) and sharding (splitting data across machines, for write scale) — and why they're usually combined, not chosen between.
Problem it solves
A single database machine has a ceiling on both storage and throughput. Replication adds read capacity and survives a machine failure by keeping copies of the same data; sharding raises the write/storage ceiling by splitting data so no single machine holds all of it. Most large systems need both: shards for write scale, each shard replicated for availability.
When not to use it
- Don't shard before you've exhausted simpler options (a bigger instance, an index, a cache) — sharding adds real operational and query complexity (no more cross-shard joins/transactions for free).
- Don't add read replicas as a substitute for caching hot, rarely-changing data — a cache is usually cheaper and faster for that specific problem.
- Don't shard on a key that doesn't match your query pattern — you'll end up fanning out to every shard on every read anyway.
Failure modes to call out
- Hot shard: a hash function or key choice concentrates traffic on one shard while others sit idle.
- Resharding causing a full data reshuffle because a naive mod-N hash was used instead of consistent hashing.
- Cross-shard queries/joins silently becoming N sequential round trips instead of one query.
- Replication lag causing a read-after-write to hit a stale replica right after the primary accepted the write.
Alternatives & trade-offs
| Alternative | Trade-off |
|---|---|
| Vertical scaling (bigger machine) | Zero application complexity, but has a hard ceiling and a single point of failure. |
| Read replicas (replication only) | Scales reads and adds failover, but every replica still holds the full dataset — doesn't help write throughput or total storage. |
| Range-based sharding | Simple to reason about and supports range queries, but can create hot shards if writes cluster in one range (e.g. timestamps). |
| Hash-based (consistent hashing) | Spreads writes evenly and minimizes data movement when a shard is added/removed, but loses efficient range queries across the shard key. |
Diagram
Consistent hashing: keys and nodes both land on a ring. Adding node D only moves the keys between C and D — every other key stays put.
Scroll the diagrams sideways to see all of them.
Estimation example
A dataset growing past 2TB on a single Postgres instance, with writes concentrated on a user_id key: sharding by a consistent hash of user_id spreads writes across, say, 8 shards (~250GB each), and each shard still gets 2-3 read replicas for availability and read scale — sharding solves the storage/write ceiling, replication solves availability, and you need both.
Say this out loud in the interview
- "Am I trying to solve a read-scale/availability problem (replication) or a write-scale/storage problem (sharding) — or both?"
- "What's my shard key, and does it match my dominant query pattern, or will I fan out to every shard?"
- "How do I add a shard later without reshuffling the whole dataset — consistent hashing, or a manageable range split?"
Practice it in a case study
Design a URL Shortener
At very large scale, the short-code → URL mapping can be sharded by a hash of the short code, with each shard replicated for availability.
Done with this lesson?
Mark it complete once you've worked through the content and practice above.
