TheLearningLoopWhy you need replication and sharding, and when to use them
One database machine has two limits. It can fail, taking your data and your service with it. And it can fill up or slow down: one machine can only hold so much data and take so many writes. Two techniques deal with these:
- Replication keeps copies of the same data on several machines.
- Sharding (also called partitioning) splits the data, so each machine holds only a part.
They give you two things interviewers always ask about:
- Availability: if a machine dies, a copy takes over (replication).
- Capacity: the data and traffic are spread over many machines, so no single one limits you (sharding, and replicas for reads).
Use replication when:
- You cannot afford to lose data or be offline if one machine fails.
- You are read-heavy: replicas serve reads and take load off the primary.
- You want a copy near users in another region.
Use sharding when:
- The data no longer fits on one machine, or writes are more than one machine can take.
- You have already used the simpler steps: indexes, caching and a bigger machine.
Skip them, or wait, when:
- One well-tuned database still has room: both add real complexity (lag, failover, cross-shard queries).
- You only need backups: replication is not a backup, because a bad delete is copied to every replica.
Try it
Start with the replication tab. Pick how copies are made, where reads go, and whether the primary crashes. Then try the sharding tab.
Primary and replicas
Step 1 of 13 · Press Space to play, arrow keys to step- Primary
v0
primary - Replica 1
v0
replica - Replica 2
v0
replica
No read this tick.
Start: one primary takes every write and copies it to two replicas. In asynchronous mode the copy arrives 2 ticks later. Pick a mode, then step through.
- latest write:
- v0
- stale reads:
- 0 of 0
- writes lost:
- 0
- in flight:
- 0
1 tick = one step of the simulation. In asynchronous mode a write reaches the replicas 2 ticks after the primary saves it.
Things to try:
- Asynchronous copying with reads from A replica: every read is stale (5 of 5 in this run), because each write takes two ticks to arrive. Switch to Synchronous: no stale reads, but each write waits for the replicas.
- Switch reads to The primary: never stale, but the replicas no longer help with reads.
- Tick Crash the primary at tick 8 with Asynchronous: a replica is promoted, and one write the client was told was saved is lost. With Synchronous nothing is lost.
- On the Sharding tab, Hash and Add a fourth shard: 9 of 12 keys move. Switch to Range: only 2 move. Then run Burst of requests for the newest keys: with ranges all 12 land on one shard, a hot spot, while hashing spreads them.
Replication and sharding strategies
| Strategy | How it works | Good when | Weakness |
|---|---|---|---|
| Primary-replica, asynchronous | One primary takes writes and copies them to replicas in the background | Read-heavy apps, most common setup | Replicas can lag; recent writes can be lost on a crash |
| Synchronous replication | The primary waits for one or more replicas to confirm before acknowledging | You cannot lose acknowledged writes | Slower writes; stalls if a replica is down |
| Multi-primary | Several nodes accept writes and sync with each other | Writes in several regions | Conflicting writes must be resolved |
| Hash sharding | A hash of the key picks the shard | Even spread of load | Range queries touch many shards; adding shards can move many keys |
| Range sharding | Each shard owns a range of keys | Range queries, sorted data | Hot spots when new data lands on the last range |
| Lookup (directory) sharding | A small table says which shard holds each key | Flexible placement | The lookup table is one more thing to keep fast and available |
Replication vs sharding
- Replication: every replica holds all the data. It adds availability and read capacity. It does not add write capacity, because every write still goes to the primary and is copied everywhere.
- Sharding: each shard holds part of the data. It adds storage and write capacity. It does not add availability on its own: if a shard is down, its part of the data is unavailable.
Large systems combine both: the data is sharded, and each shard has its own replicas.
How failover and rebalancing work
Failover (when the primary dies):
- Detect: replicas or a monitor notice the primary has stopped answering for a few checks in a row.
- Choose: pick the replica that is most up to date.
- Promote: make it the new primary, so it accepts writes.
- Redirect: point clients and the other replicas at the new primary.
- Repair: when the old primary returns, make it a replica, and discard writes it had that never got copied.
The dangers: writes that were only on the old primary are lost (asynchronous mode), and if two nodes both think they are the primary (split brain), their data diverges. Real systems use a majority vote to decide who is primary.
Rebalancing (when you add or remove a shard):
- Decide which keys belong on the new layout.
- Copy the moving keys to their new shard while the old copy still serves reads.
- Switch the routing to the new location.
- Delete the old copies.
How many keys move depends on the scheme. Hash mod N moves most keys, ranges move few, and consistent hashing is designed to move only about 1 / N of them.
Replicas and shards vs the alternatives
| Concern | Replication + sharding | Bigger single database | Caching in front | Read replicas only |
|---|---|---|---|---|
| Survives a machine failure | Yes | No | Not by itself | Yes for reads, writes need failover |
| Scales writes | Yes (sharding) | Up to a ceiling | No | No |
| Scales reads | Yes | Up to a ceiling | Yes | Yes |
| Simple to run | No | Yes | Mostly | Mostly |
| Strong consistency across all data | Harder | Yes | Not guaranteed | Reads can be stale |
| Best for | Very large data and traffic | Most products at first | Repeated reads | Read-heavy, modest size |
Start with the simplest step that solves your actual limit. Most systems need replicas long before they need shards.
Avoiding a new single point of failure
These techniques add parts that can fail:
- The failover process itself. If nothing promotes a replica, a copy does not help. Automate it and practise failover regularly.
- Split brain. Use a majority (an odd number of voters) so only one primary can exist.
- The shard map. Whatever tells clients which shard holds a key must be fast and highly available.
- A whole data centre or region. Put replicas in another zone or region if you must survive that.
- Backups. Replicas copy mistakes. Keep real backups too.
The trade-off: extra machines and moving parts, and for asynchronous setups a window where recent writes can be lost.
Common mistakes
- Reading your own write from a lagging replica. A user saves a change and does not see it. Read from the primary right after a write, or route that user to the primary briefly.
- Treating replicas as backups. A bad delete or a corrupted row reaches every replica. Take real, tested backups.
- A bad shard key. An increasing ID or a timestamp sends all new writes to one shard. Pick a key that spreads load and keeps related data together.
- Cross-shard joins and transactions. They are slow and hard. Design so the common queries stay on one shard.
- Sharding too early. It is hard to undo. Use indexes, caching and replicas first.
- Never testing failover. The first time it runs should not be during an outage.
How to talk about replication and sharding in an interview
- Separate the two ideas: "replication for availability and reads, sharding for capacity and writes."
- Name the shard key and why: it spreads load, keeps related data together, and fits the main queries.
- Say sync or async and what you accept: "async for speed, accepting a small window of possible loss", or "sync for no loss, accepting slower writes."
- Mention unprompted: failover, replication lag and read-your-writes, hot spots, and how you would add a shard.
- Name the trade-off in one sentence.