Replication strategies
Choose how copies of the data stay in step, trading write latency and lost writes against stale reads and complexity.
Replication keeps more than one copy of the data, and the strategy decides when a write counts as done.
Use it when#
One machine failing must not lose data or stop reads.
Reads outnumber writes and one copy cannot serve them all.
Users in other regions need a copy near them.
How it works#
There are four common shapes.
Leader and followers, asynchronous. The leader confirms at once and followers catch up. Writes are fast, a follower can lag, and a leader that dies can lose the last writes.
Leader and followers, synchronous. The leader waits for a follower. Nothing confirmed is lost, and every write pays the round trip.
Leaderless. A client writes to several replicas and reads from several, and the quorum rule decides what a read sees.
Consensus. A majority must agree on each write, so the group survives a minority failing. See consensus and leader election.
What it costs#
Each shape gives up something. Asynchronous copies serve stale reads and lose writes in a crash, synchronous ones slow every write and stop writes if the replica goes down, and leaderless stores need quorum math. Accepting writes on more than one node, as multi-leader and leaderless setups do, adds write conflicts that someone must resolve. Replication also does not protect against a bad delete, because the delete replicates too, so keep backups.
In Quorum#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | medium | Medium, so the App Server is not the limit. |
| Database | Instance size | medium | Medium. It takes every write and waits for the replica. |
| Read Replica | Synchronous | On | Every write waits for this replica before it is confirmed, so the replica never lags and serves no stale read. |
| Read Replica | Instance size | medium | The same size as the primary, because it repeats every write. |
Research this Design needs: Read replicas, Read replicas, Synchronous replication.
A Read Replica is asynchronous by default, so it lags and some reads come back stale. Turning on Synchronous makes every write wait for it, which removes stale reads and adds a round trip, and if the replica goes down, writes time out until it returns. It needs Synchronous replication after Read replicas.
The Wide-column Store is leaderless, and Distributed SQL is consensus. The Replication lag incident shows the asynchronous cost. The glossary defines synchronous replication and replication lag.