Replication and sharding
In short: Replication keeps copies of the same data on several nodes for availability and read scale. Sharding splits data into partitions spread across nodes for write scale and capacity. Real systems usually shard the data and then replicate each shard.
Two different goals
Replication stores the same data on several nodes. If one fails, another has a copy, and read traffic can be spread across replicas. Sharding (also called partitioning) divides the data so each node holds only part of it. This lets the total data and write load grow beyond one machine. Most large databases shard first, then replicate each shard three times or so.
Replication topologies
- Single leader (primary and replicas): all writes go to one node, which streams changes to followers. Simple and widely used, for example in PostgreSQL and MySQL streaming replication.
- Multi-leader: several nodes accept writes, often one per data centre. Good for multi-region writes, but concurrent edits to the same record must be resolved.
- Leaderless: clients write to and read from several replicas. With n replicas, a write quorum w and a read quorum r, choosing w + r > n means reads overlap with the latest write. Cassandra-style databases work this way.
Timing matters too. Synchronous replication waits for a replica to confirm before acknowledging the client, so no acknowledged write is lost, but it is slower. Asynchronous replication is fast, but if the leader dies, recent writes may be lost and replicas lag behind.
Sharding strategies
| Strategy | How it works | Strength | Weakness |
|---|---|---|---|
| Range | Keys split by ranges, such as A-F, G-M | Efficient range scans | Hot spots if keys are sequential, such as timestamps |
| Hash | Hash of the key picks the shard | Even spread of load | Range queries hit every shard |
| Consistent hashing | Keys and nodes placed on a hash ring | Adding a node moves few keys | Needs virtual nodes for balance |
| Directory | Lookup table maps keys to shards | Flexible placement | Directory is a critical dependency |
The shard key is the most important choice. Pick one that spreads load evenly and keeps data that is queried together on the same shard, such as customer ID for an order system.
Common pitfalls
- Replication lag: readers on followers see old data (see consistency models).
- Failover data loss: promoting an asynchronous follower can drop the last writes.
- Hot shards: one celebrity user or one busy day can overload a single shard.
- Cross-shard work: joins and transactions across shards are slow and complex.
- Resharding: moving data to new shards while live needs careful planning and tooling.
Tip: replication is not a backup. A mistaken DELETE replicates to every copy within seconds. Keep separate, versioned backups.
At work, check replication health regularly. On PostgreSQL, for example, you can view replica status from the primary:
SELECT client_addr, state, sync_state, replay_lag FROM pg_stat_replication;Practice
With 3 replicas, which quorum values guarantee a read overlaps the latest write?
Why can sharding by timestamp cause problems?
Does replication protect against accidental deletion?
Key takeaways
- Replication copies data; sharding splits it.
- Single-leader, multi-leader and leaderless are the main topologies.
- Synchronous replication is safer; asynchronous is faster.
- Choose the shard key to spread load and keep related data together.
- Replication is not a backup.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.