Replication & Sharding
Understand data replication strategies (master-slave, master-master) and horizontal partitioning (sharding) for scalability.
Strategy
Controls
What's happening?
Writes flow into the master node and replicate outward. Watch the nodes pulse when a replication event is in-flight. In Master-Slave, only one node accepts writes and pushes to read replicas. In Master-Master, both nodes accept writes and sync bidirectionally. In Sharding, data is partitioned by key range — each shard is independent.
Why it matters?
Replication is how databases achieve high availability and durability. Master-Slave scales reads cheaply but the master is a single point of failure. Master-Master removes that bottleneck but requires conflict resolution for concurrent writes. Sharding is the only strategy that scales writes — it's how Google Spanner and Cassandra handle planetary-scale data.
Why this exists
Replication copies data to improve availability and read scale. Sharding splits data across nodes to increase total write throughput and storage capacity. Replication preserves the same dataset in more places. Sharding divides the dataset itself.
Replication improves resilience
Multiple copies let the system survive node loss and absorb more reads, but introduce lag and failover complexity.
Sharding raises the ceiling
Partitioning data across nodes lets the system store and write more than one box can handle, but makes routing and rebalancing harder.
They solve different bottlenecks
Replication helps when the same data is being read too often. Sharding helps when one node cannot hold or write the whole dataset anymore.
Key takeaways
- Replication is about copies. Sharding is about splitting.
- Read scale and write scale are different problems.
- Failover, lag, and consistency become more visible with replication.
- Shard keys determine whether scaling is smooth or painful.