Database Replication: Single-Leader, Multi-Leader & Leaderless
Keeping multiple copies of the same data close enough to identical that a client can't tell which copy just answered.
Intermediate
TopNotchNote
Notes that matter
why replicate at all
A single database server is a single point of failure and a single ceiling on read throughput. Replication keeps multiple copies of the same data on different machines (ideally in different racks or regions), so a failed node doesn't take the whole service down and reads can be spread across copies. The hard part isn't making the copies — it's keeping them close enough to identical that a client can't tell which copy answered.
single-leader replication
The most common model: one node (the leader, or primary) accepts all writes; one or more followers (replicas) receive a copy of every change and serve read traffic.
For PlateRoute, this means every
UPDATE orders ... goes to the leader, but a read-heavy query like "show me this restaurant's order history" can be served from a follower without touching the leader at all — spreading read load across as many followers as needed.| Pro | Con | |
|---|---|---|
| Single-leader | Simple mental model; reads scale by adding followers; a follower can be promoted to leader on failure | All writes still funnel through one node — a write-heavy workload eventually bottlenecks there |
sync vs. async replication — the CAP trade-off again
| Mode | Behavior | Trade-off |
|---|---|---|
| Synchronous | The leader waits for a follower to confirm the write before acknowledging it to the client. | Zero data loss if the leader fails right after, but higher write latency, and availability drops if that follower is slow or unreachable. |
| Asynchronous | The leader acknowledges the write immediately and replicates to followers in the background. | Low write latency, but a leader crash right after a write can lose data that never made it to any follower — and followers can serve stale reads until they catch up. |
This is the same C-vs-A tension from the CAP theorem, one layer down: synchronous replication favors consistency, asynchronous favors availability and latency. A payments table might replicate synchronously to at least one follower; a table of restaurant view-counts is a fine candidate for asynchronous replication, where a few seconds of staleness costs nothing.
multi-leader replication
Sometimes one write bottleneck genuinely isn't good enough — a globally distributed app wants writes to land at the nearest datacenter rather than crossing the ocean to a single leader every time. Multi-leader replication allows several nodes to each accept writes, syncing changes with each other afterward.
This solves the single-write-bottleneck problem and improves write latency for geographically distributed users, but introduces a new one: conflict resolution. If a US leader and an EU leader both accept a conflicting update to the same record before syncing, something has to decide which one wins — often last-write-wins by timestamp, or a merge rule specific to the data.
leaderless (peer-to-peer) replication and quorums
A third model removes the concept of a leader entirely: any node can accept a read or write, and replication happens via a quorum protocol. With
n replicas, a write must be acknowledged by at least w of them, and a read must query at least r of them. As long as w + r > n, at least one node in any read set is guaranteed to have seen the latest write.
n = 3 replicas, w = 2, r = 2
w + r = 4 > n = 3 -> every read overlaps with at least one up-to-date replica
This is the model used by Dynamo-style key-value stores (see Key-Value Stores & the Dynamo Model) and by Cassandra. It has no single point of failure and tunes cleanly between consistency and availability by adjusting
w and r — but it pushes conflict resolution to the client or a merge strategy, since with no single leader there's no natural "correct" order for concurrent writes to the same key.