One database server holds your data. The disk dies. You lose everything. Replication — keeping copies on multiple servers — solves three problems at once: durability (survive hardware failures), availability (serve reads when one replica is down), and read scale (spread reads across replicas).
It introduces two hard problems: when is a write "done" (replica 1? all replicas?) and what happens when replicas disagree. Every DB answers these differently.
All writes go to one leader. The leader ships the change log to N followers. Reads can go anywhere. Simple, well-understood, works for 90% of systems. Postgres, MySQL, MongoDB, Redis default to this.
Multiple leaders, each in a different datacenter. Writes are eventually reconciled across leaders. Used for multi-region active-active. Conflict resolution is the hard part — last-write-wins, CRDTs, or application-level merging.
Writes and reads go to any N nodes. Quorum rules (W + R > N) ensure consistency. Cassandra, DynamoDB. Maximum availability, weakest consistency.
A write arrives at the leader. The leader can:
For money: always sync. For social media: async is usually fine (a second of replica lag is invisible; an outage from a slow replica is catastrophic).
1. Read-your-own-writes. User posts a photo. Write goes to leader. User immediately refreshes — read goes to a lagging replica that doesn't have the photo yet. User panics, re-uploads. Two photos now exist.
Mitigation: route writes and the user's subsequent reads to the same replica for some window (session stickiness). Or force reads-after-writes to hit the leader for a few seconds.
2. Monotonic reads. User refreshes the comment thread: reads from replica A, sees 10 comments. Refreshes again: reads from replica B (more lagged), sees 8. The count went backward.
Mitigation: route each user to a consistent replica (hash by user ID). Or use consistent-read APIs.
3. Failover split-brain. Leader briefly unreachable. Ops promotes a follower to leader. Original leader comes back, still thinks it's leader. Two leaders accept conflicting writes.
Mitigation: fencing tokens (every write includes a monotonically-increasing token; stale leader's writes get rejected). Consensus (Raft/Paxos) picks the unambiguous leader. Never rely on "if I can't reach the other node, I'm the leader."
Ships the WAL to followers. Set synchronous_commit=on + synchronous_standby_names for sync. Standard pattern for most apps.
Plugin that lets any node accept writes. Uses Paxos for conflict resolution. Tricky to run; most shops stick with leader-follower.
W + R > N quorum. Writes to any N replicas; reads from any R. Tunable per query.
Each region is a leader for local writes. Cross-region conflicts resolved last-write-wins. Under 1 second typical convergence.
URL shortener uses leader-follower Postgres. Payment gateway uses synchronous replication for the ledger. News feed uses Cassandra's leaderless model for the feed store. WhatsApp uses cross-region multi-primary for message delivery.
