What is Replication

Replication keeps several copies of one dataset in agreement by funnelling every write through a single authoritative copy (the leader), recording each committed change as an ordered stream of records — the replication log — which every follower pulls and replays in the same order, so any copy can serve reads and any copy can take over when another dies. The whole idea reduces to that one mechanism: an ordered log, replayed everywhere, drives the copies to the same state.

Concretely, the leader appends each committed change to its write-ahead log at a monotonically increasing offset; every follower keeps a cursor into that log and applies records up to its current offset. The gap between the leader's newest offset and a follower's applied offset is the replication lag. That single mechanism buys three distinct things: availability (a copy survives a node loss), read scale-out (spread reads across copies), and locality (place a copy next to the reader).

Redundancy vs. replication

They are related but not synonyms. Redundancy is the goal — eliminate single points of failure by having more than one of something. Replication is one mechanism that delivers data redundancy, and its defining trait is that copies are kept in sync continuously, in near-real-time — not snapshotted every few hours the way a backup is.

Note the nuance: a replica can be active (serving reads) or a passive hot standby (kept current but idle until promoted). So the popular line "replication is active, all copies are utilized" is too strong — whether a copy serves traffic is a deployment choice; the trait that actually defines replication is continuous synchronization.

Sync, async, semi-sync: it is all about when the client hears "OK"

The three replication modes differ in exactly one decision: how many followers must acknowledge a write before the leader reports it committed to the client. Everything else — durability, write latency, blast radius of a slow node — follows from that.

• Asynchronous — the leader acks the client the moment it commits locally, then ships the log in the background. Lowest write latency, but acknowledged writes can vanish if the leader dies before shipping them (a non-zero recovery point objective, RPO > 0), and reads from a lagging follower are stale. The size of that loss window is roughly RPO ≈ replication_lag × write_rate: 120 ms of lag at 800 writes/s leaves ≈96 acknowledged writes unshipped and at risk on a crash.
• Synchronous — the leader waits for a configured set of followers to ack before it acks the client. Those replicas are guaranteed to have the write (RPO = 0 for them), but every write now pays the slowest follower's round trip, and one dead follower stalls all writes.
• Semi-synchronous — wait for k of N followers (usually k = 1). The pragmatic middle: the write is durable on at least one other node, latency is bounded by the fastest replica, and if that replica is local the far WAN copies stay async.

Worked example: one profile update, traced

Topology: leader in us-east; follower A in the same AZ (network ~0.5 ms one-way); follower B in eu-west (~40 ms one-way over the WAN). A user runs UPDATE users SET bio = 'hi' WHERE id = 42. Here is the async timeline, step by step.

Between t = 0.5 ms and t = 40 ms, follower B still serves the old bio. A European user routed to B who reads right after writing sees their change "missing" — the classic read-your-writes anomaly (mechanics and fixes are covered on Replication Lag & Failover). The same write under the three modes:

Note the ack is a round trip: sync-to-eu-west costs ~80 ms, twice the 40 ms one-way shipping time the async table row shows — a follower having the write and the leader knowing it has it are separated by the return leg. For any topology, synchronous ack time ≈ local commit + 2 × one-way latency to the slowest required follower (plus its apply time).

Pitfalls

• "Replication is my backup." It is not. A mistaken DELETE FROM users or a corrupt page replicates to every copy in milliseconds — replication faithfully copies the mistake. You still need point-in-time backups and snapshots for logical recovery.
• Async data-loss window on failover. With async replication, writes the client was told succeeded may never have left the dying leader. Promoting a follower silently drops them. If RPO must be zero, at least one synchronous replica is mandatory.
• Synchronous replication couples your availability to your slowest replica. Configure sync to all replicas and a single GC pause, disk stall, or dead node freezes every write cluster-wide. Use semi-sync with a timeout that falls back to async, or count a quorum rather than "all".
• Single-threaded replay can't keep up. Followers that apply the log serially while the leader commits in parallel develop unbounded, ever-growing lag under write bursts — the follower is never "a bit behind," it is falling behind forever. Watch replica-apply lag, not just network lag.
• Reading from replicas without accounting for lag. Dashboards, "did my payment go through?" checks, and uniqueness validations that read a stale follower produce wrong answers. Route read-after-write and correctness-critical reads to the leader (or a synchronously-updated replica).

When to use it — and when not

Reach for replication when you see these signals: read traffic dwarfs writes (spread reads across copies); you cannot tolerate a single node's death (keep a hot standby to promote); or readers are geographically spread (put a copy near them). Then pick the mode by what you cannot afford to lose:

• Choose sync / semi-sync when losing an acknowledged write is unacceptable — payments, ledgers, order placement. Accept the extra write latency; use semi-sync (k = 1 local replica) so one WAN hiccup doesn't halt writes.
• Prefer async when write latency and availability beat perfect durability — activity feeds, analytics, session data, most read-heavy web apps. Accept a small data-loss window and stale reads.

Trade-offs vs. named alternatives

• vs. Partitioning / sharding. Replication copies the whole dataset to every node, so it scales reads and gives HA — but every node still absorbs the full write volume, so it does not scale writes and does not grow capacity beyond one machine's disk. When the write rate or dataset size exceeds a single node, you need partitioning (split the data), and in practice you combine the two: shard, then replicate each shard. Choose replication alone when the working set fits one node and the pain is read throughput or availability; add partitioning once writes or size are the bottleneck.
• vs. a single bigger node (scale up). One beefy primary has no replication lag, no stale reads, no split-brain — the simplest correct system. Its cost is a hard availability ceiling: when it dies, you are down, and there is no read fan-out or geographic locality. Choose scale-up while a single node comfortably serves the load and a few minutes of downtime is acceptable; introduce replication the moment either assumption breaks.

Rule of thumb: replicate for availability and read scale; partition for write scale and capacity; stay single-node while you honestly can.

Takeaways

• Replication is one mechanism — an ordered replication log replayed by every copy — not a synonym for redundancy and not a backup.
• Sync, async, and semi-sync differ only in how many followers must ack before the client hears "OK"; that one knob sets your durability (RPO), write latency, and how a slow node hurts you.
• Async trades a small data-loss window and stale reads for speed and availability; sync trades latency and a shared fate with your slowest replica for zero loss. Semi-sync is the common compromise.
• Replication scales reads and buys HA — but a single node still eats every write, so reach for partitioning when writes or dataset size are the real bottleneck.

Sources: Martin Kleppmann, Designing Data-Intensive Applications, ch. 5 (Replication) — leaders, followers, replication logs, sync vs. async, and lag; PostgreSQL documentation on streaming replication and synchronous_commit; MySQL documentation on semisynchronous replication (rpl_semi_sync) and its timeout fallback. Re-authored / deepened for this guide; lag anomalies, failover, split-brain, and fencing are treated on the companion page "Replication Lag & Failover."