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.

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.

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.

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.