Replication Methods

Replication keeps multiple copies of the same data on different nodes, and the single decision that distinguishes every method below is where a write is allowed to land and how that write then propagates to the other copies — that one choice fixes the system's consistency, write-availability, and latency together.

Read the seven methods as points on two axes: how many nodes accept writes (one, several, or any) and how the copy is made (streamed per-change vs. a bulk snapshot). Failover behaviour, conflict handling, and read scaling all fall out of those two choices.

1. Single-leader (primary-backup)

Mechanism: one node is the sole writer; it appends every committed change to an ordered log and followers replay that log to converge on the same state. Because all writes pass through one node, they are totally ordered for free and no write conflict is ever possible.

Real system — MySQL: the primary records each committed change in its binlog; replicas open a replication connection, pull binlog events, and replay them (statement- or row-based). PostgreSQL does the same by streaming WAL records (see method 5).

Pros

• Conflict-free writes — a single writer means a single total order.
• Easy to reason about; failover is “promote a follower”.
• Followers can serve reads and act as warm standbys.

Cons

• The leader is a single point of write failure and a throughput ceiling.
• A short window of unavailability during failover (promote + redirect).
• Followers lag under heavy write load, so replica reads can be stale.

2. Multi-leader replication

Mechanism: several nodes each accept writes and asynchronously ship their changes to the other leaders, which merge them; because two leaders can edit the same key concurrently, the system must detect and resolve conflicts (last-write-wins, a version-vector merge, a CRDT, or an application callback).

Real system — CouchDB bidirectional sync: each node accepts updates and exchanges changesets over HTTP; conflicting revisions are kept and flagged for deterministic or callback-based resolution.

Pros

• Writes stay local in each region (low write latency, geo-locality).
• Higher write availability — a partition still leaves each side writable.
• Supports offline clients that reconcile on reconnect.

Cons

• Conflict resolution is real design work and easy to get wrong.
• Histories can diverge if a sync is missed or delayed.
• Extra metadata (version vectors, change logs) to carry and reason about.

3. Leaderless (quorum-based) replication

Mechanism: no node is privileged — a client (or coordinator) sends each write to all N replicas and treats it as done once W of them acknowledge; a read queries R replicas and takes the newest version it sees. Configure R + W > N and the read set and the write set are guaranteed to share at least one replica, so at least one responding node always holds the latest write.

Real system — Apache Cassandra / Riak (and the original Amazon Dynamo): tunable per query, e.g. N=3 with W=QUORUM and R=QUORUM. Divergences are healed by read repair and anti-entropy in the background.

Pros

• No single point of failure and no write bottleneck.
• Consistency vs. latency is tunable per query via R, W, N.
• Stays available and writable through node loss, and through partitions on any side that can still reach W replicas; staying writable on a minority side requires sloppy quorums — see the “Sloppy quorums lie about durability” pitfall below.

Cons

• No global order of writes; concurrent writes need a merge rule.
• Mis-tuned quorums (R + W ≤ N) silently allow stale reads.
• Operationally subtle: read repair, hinted handoff, and clock skew all bite.

Worked trace — why R + W > N works (N=3, W=2, R=2)

Three replicas A, B, C all start holding x = 5 (version 1). Watch a write race a read:

The write set was {A, B} and the read set was {B, C}. Since 2 + 2 > 3, those sets must overlap — here at B, which carries v2 — so the read is guaranteed to observe the newest write and the client picks the highest version. Drop to W=1 (so R + W = 3 = N) and the sets can miss each other entirely: a write to {A} then a read of {B, C} would return the stale x = 5. That inequality, not any magic, is the whole guarantee.

4. Chain replication

Mechanism: replicas are arranged in a fixed line; every write enters at the head and is forwarded node-by-node down to the tail, and only the tail serves reads and acknowledges the client. A read at the tail therefore reflects every write the tail has already forwarded — you get strong consistency while spreading the update work along the chain.

Provenance — this is not a Google design. Chain replication was introduced by Robbert van Renesse and Fred B. Schneider at Cornell in the OSDI 2004 paper “Chain Replication for Supporting High Throughput and Availability.” It later influenced systems such as Microsoft's CORFU and various object stores, but the invention — and the write-flows-head-to-tail, reads-and-acks-at-tail protocol — is theirs.

Pros

• Strong consistency: the tail holds a fully ordered, committed state.
• High throughput via pipelining down the chain.
• Well-defined recovery: drop the failed link and re-link its neighbours.

Cons

• Write latency grows with chain length (one hop per node).
• Any link failure stalls writes until the configuration manager reconfigures the chain.
• Reads concentrate on the tail unless you add read-only tail replicas.

5. Read-replica replication

Mechanism: a single-leader setup tuned for read fan-out — the leader owns all writes and a fleet of replicas continuously replay its change stream but never accept writes, existing purely to absorb read traffic.

Real system — PostgreSQL streaming replication: the primary writes changes to its Write-Ahead Log (WAL); standbys connect over the streaming protocol, replay WAL records in near-real time, and expose the data as read-only hot standbys that can also be promoted on failover.

The distinction from plain single-leader is intent: single-leader replicas exist mainly for failover/backup and may serve reads; read-replicas are provisioned in bulk (dozens or hundreds) specifically to scale reads and can be placed near users for latency.

Pros

• Read scalability — offload heavy read queries from the primary.
• Reads never block writes on the primary.
• Geographic placement reduces read latency; replicas double as failover targets.

Cons

• Stale reads from replication lag.
• No write distribution — the single leader is still the write ceiling.
• Operational overhead: monitoring lag, drift, and failover.

6. Snapshot replication

Mechanism: instead of shipping every change, the source periodically captures a full, point-in-time copy of the dataset and pushes that entire snapshot to subscribers, which replace their local data with it.

Real system — SQL Server snapshot replication: at publication time the server bulk-generates a snapshot of the tables and schema, delivers it (often via file share), subscribers apply it wholesale, and the cycle repeats on a schedule (e.g. nightly).

Pros

• Simple: no change-tracking or continuous log-shipping pipeline.
• Each snapshot is a consistent, point-in-time view.
• Great for static or slow-changing reference data.

Cons

• Heavy periodic IO and network load from recopying everything.
• Latency: changes appear only after the next snapshot.
• Not incremental — a one-row change still triggers a full transfer unless you layer differential/CDC on top.

7. Hybrid replication

Mechanism: compose the above per layer of the topology — e.g. multi-leader between two data centres for cross-region write locality, and read-replica replication within each data centre to scale local reads.

• Pros: tailors the strategy to different tiers, optimising for both write locality and read scale.
• Cons: the most moving parts; conflicting behaviours (e.g. lag stacking on top of cross-region conflict resolution) if the layers aren't coordinated.

Pitfalls

• Replication lag breaks read-your-writes. A user updates their profile on the leader, then a follow-up read hits a lagging replica and shows the old value. Fix: route a user's own reads to the leader for a few seconds after their write, or record the write's log position (LSN) and only read from a replica that has caught up to it.
• Split-brain on failover. A leader that is merely partitioned (not dead) plus a newly promoted leader = two writers; in multi-leader this divergence can become permanent. Guard promotion with fencing tokens or a consensus-based lease, never a bare timeout.
• Last-write-wins silently drops data. Leaderless and multi-leader often resolve conflicts by wall-clock timestamp; a few milliseconds of NTP skew can let an older write “win” and overwrite a newer one with no error. Prefer version vectors or CRDTs when concurrent writes to one key are expected.
• Chain: the tail is a read hotspot, and a mid-node crash stalls writes until the configuration manager (typically Paxos/ZooKeeper-backed) removes the dead link and re-links its neighbours.
• Snapshot IO storms. Scheduled full recopies saturate disk and network, and a tiny change still costs a full transfer unless you add differential/CDC.
• Sloppy quorums lie about durability. With hinted handoff, W acks can come from stand-in nodes that are not the key's real replicas; the write looks durable, but a later R + W > N read is no longer guaranteed to see it.

When to use which (and when not)

• Single-leader — choose when total write throughput fits one node and you want dead-simple strong ordering, transactions, and read-your-writes with no ceremony (classic OLTP on Postgres/MySQL). It costs a write ceiling and a brief failover gap. Prefer leaderless when you cannot tolerate that failover pause or that ceiling.
• Multi-leader — choose only when you genuinely need writes in more than one region, or offline clients that sync later. It costs conflict-resolution logic you must design and the risk of divergent history. Prefer single-leader if one region's write latency is acceptable — the conflict machinery rarely pays for itself otherwise.
• Leaderless quorum — choose when write availability during node loss and per-query tunable consistency matter more than a global order (Cassandra, Riak, Dynamo). It costs ordering, debuggability, and correctness that hinges on R + W > N with honest quorums. Prefer single-leader when you need multi-key transactions and simple semantics.
• Chain vs. leaderless — both remove the single write bottleneck. Chain buys strong consistency plus high pipelined throughput at the price of latency proportional to chain length and a dependency on an external configuration manager; leaderless buys higher availability and lower write latency but only eventual/tunable consistency. Choose chain in a controlled cluster that needs strong consistency and throughput; prefer leaderless when partition tolerance and availability dominate.
• Read-replica, snapshot, hybrid are not separate consistency models — read-replica is single-leader tuned for read fan-out, and snapshot/hybrid are operational overlays. Reach for snapshot only for static/slow data, and hybrid only when no single method covers both the cross-region and intra-region need.

Takeaways

• The whole taxonomy collapses to two questions: how many nodes accept writes, and is propagation per-change or bulk snapshot.
• One writer gives you free total ordering but a bottleneck and a failover gap; many writers give availability but conflicts you must resolve.
• Leaderless correctness is arithmetic: R + W > N forces the read and write sets to overlap — nothing more magical, and it fails the moment quorums are sloppy or clocks are skewed.
• Chain replication is van Renesse & Schneider (Cornell, OSDI 2004), not Google — get the provenance right.

Sources: van Renesse & Schneider, “Chain Replication for Supporting High Throughput and Availability,” OSDI 2004 (Cornell); Martin Kleppmann, “Designing Data-Intensive Applications,” ch. 5, for single-/multi-leader, leaderless quorums, and the R + W > N overlap argument; DeCandia et al., “Dynamo: Amazon's Highly Available Key-value Store,” SOSP 2007; MySQL binlog and PostgreSQL WAL streaming-replication documentation; Microsoft SQL Server snapshot-replication documentation. Re-authored / deepened for this guide.