Database Replication

Replication keeps copies of the same data on multiple database nodes so the system can survive machine failures and serve more read traffic. The two dominant topologies are leader-follower replication and multi-leader replication.

In leader-follower replication (also called primary-replica), one node accepts all writes and streams its change log to read-only followers. Clients read from any replica, which scales reads horizontally, while writes funnel through the single leader.

In multi-leader replication, several nodes each accept writes and replicate to one another, which helps multi-region deployments and offline-capable clients but introduces write conflicts that must be detected and resolved.

Replication can be synchronous (the leader waits for a follower to acknowledge before committing) or asynchronous (the leader commits immediately and ships changes later). Async replication creates replication lag, which means a follower can serve slightly stale data. That staleness is exactly the concern captured by Consistency Models, and the choice to keep serving reads during a network split versus refusing them is the availability-versus-consistency decision described by the CAP Theorem.

Synchronous replication protects durability and freshness but adds write latency and stalls if a replica is slow. Asynchronous replication is fast and resilient to slow replicas but risks losing recently acknowledged writes if the leader fails before they propagate. Leader-follower is simple but the leader is a write bottleneck and a failover point; multi-leader removes that bottleneck at the cost of conflict resolution.

• When you add replicas, immediately state sync-vs-async and who reads from where.
• Mention read-after-write consistency: a user who just wrote may read a stale follower unless you route them to the leader.
• Explain your failover story rather than assuming the leader never dies.