Database Replication
Replication keeps copies of the same data on multiple database nodes, serving two goals simultaneously: fault tolerance (if one node dies, another has the data) and scalability (multiple nodes can serve read traffic in parallel). Every replication scheme faces the same fundamental tension — keeping replicas perfectly in sync requires coordination that costs latency, while allowing replicas to fall behind risks serving stale reads. How a system resolves this tension defines its replication topology and consistency guarantees.
Cricket analogy: Replication is like a franchise keeping backup wicketkeepers who train identically to the starter — if the starter is injured, a backup steps in seamlessly, and multiple trained keepers can also help run separate net sessions in parallel, but keeping every keeper perfectly drilled to the same standard takes coaching time.
Leader-follower (primary-replica) replication
The most common topology designates one node as the leader, which accepts all writes, and one or more followers that replicate the leader's changes and typically serve read traffic. This cleanly avoids write conflicts since there's only one writer, and it scales read capacity horizontally by adding more followers. The tradeoff is that the leader is a single point of write availability — if it fails, a follower must be promoted, and any writes not yet replicated at failure time can be lost.
Cricket analogy: Leader-follower replication is like a single official scorer (the leader) who alone updates the master scorebook, while assistant scorers (followers) copy it down and can answer fan questions from their copies — if the official scorer collapses, an assistant must be promoted, but any run scored right before the collapse might be lost.
Synchronous vs. asynchronous replication
In synchronous replication, the leader waits for acknowledgment from one or more followers before confirming a write to the client, guaranteeing those followers are up to date but adding latency to every write and risking availability loss if a follower is slow or down. In asynchronous replication, the leader confirms the write immediately and replicates in the background, giving lower write latency but creating replication lag — a window where followers (and thus read replicas) serve data that doesn't yet reflect the latest write. Semi-synchronous setups wait for just one follower to acknowledge, balancing durability and latency.
Cricket analogy: Synchronous replication is like a captain waiting for the third umpire's confirmed decision before restarting play — safe but slow; asynchronous is like play continuing immediately while the review updates in the background, faster but risking a brief window of an outdated scoreboard; semi-sync waits for just one confirming replay angle.
Multi-leader and leaderless replication
Multi-leader replication allows writes to multiple nodes (often one per data center), which improves write availability and latency for geographically distributed users but introduces the possibility of conflicting writes to the same data that must be reconciled (last-write-wins, application-level merge logic, or CRDTs). Leaderless replication, used by systems like DynamoDB and Cassandra, sends writes to multiple replicas directly from the client and uses quorum reads/writes (requiring acknowledgment from a majority of replicas) to tolerate individual node failures without a single point of coordination.
Cricket analogy: Multi-leader replication is like allowing scorers at both the stadium and a satellite broadcast van to independently log runs, which is fast but risks conflicting entries needing reconciliation; leaderless replication is like several independent scorers all logging directly, with the final total accepted only once a majority of their tallies agree.
Leader-follower replication with async lag:
Client -> Leader: WRITE user.name = "Priya"
Leader -> Client: ACK (write committed on leader)
Leader -> Follower A: replicate (async, arrives 40ms later)
Leader -> Follower B: replicate (async, arrives 120ms later)
Client -> Follower B: READ user.name (30ms after write)
Follower B -> Client: "old_name" <- stale read (replication lag)
Quorum write/read (leaderless, N=3 replicas, W=2, R=2):
Client writes to 3 replicas, waits for 2 ACKs -> committed
Client reads from 2 replicas; if they disagree, take the newer version
W + R > N guarantees read and write sets overlap by at least one replicaMySQL and PostgreSQL both default to leader-follower replication with asynchronous replicas used for read scaling and disaster recovery, while systems like Cassandra and DynamoDB use leaderless, quorum-based replication to achieve high write availability across many nodes without a single leader bottleneck.
A common mistake is routing read-after-write operations (e.g., a user updates their profile then immediately reloads the page) to an asynchronous read replica, which may not yet have the update — producing a confusing 'my change disappeared' bug. Read-your-writes consistency usually requires routing such reads to the leader or a replica known to be caught up.
- Replication improves both fault tolerance (redundant copies) and read scalability (parallel read capacity).
- Leader-follower replication avoids write conflicts by funneling all writes through a single leader.
- Synchronous replication guarantees follower freshness at the cost of write latency; async replication is faster but risks stale reads.
- Multi-leader replication improves write availability across regions but requires conflict resolution.
- Leaderless, quorum-based replication (W + R > N) tolerates node failures without a single coordination point.
- Read-after-write bugs commonly arise from routing fresh reads to a lagging asynchronous replica.
Practice what you learned
1. What is the main advantage of leader-follower replication over allowing writes to any node?
2. What is the tradeoff of synchronous replication compared to asynchronous replication?
3. In quorum-based leaderless replication with N=3, W=2, R=2, why does W + R > N matter?
4. What causes a 'read-after-write' bug where a user's own update appears to have disappeared?
5. What problem does multi-leader replication introduce that leader-follower replication avoids?
Was this page helpful?
You May Also Like
The CAP Theorem
A foundational result stating that a distributed data store can only guarantee two of consistency, availability, and partition tolerance at once, shaping every distributed database's design.
Consistency Models
Consistency models define the contract about what values reads may return after concurrent writes, ranging from strict linearizability to loosely-ordered eventual consistency.
Database Sharding
Explains how sharding partitions a dataset horizontally across multiple database nodes to scale beyond what a single machine can hold, and the tradeoffs of common sharding strategies.
Redundancy and Failover
Techniques for eliminating single points of failure by duplicating critical components and automatically routing traffic away from failed instances to healthy ones.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics