Database Replication: Master-Slave, Master-Master, and Quorum Reads

Three topologies

Single-leader (master-slave):

• One leader takes all writes; followers replicate; reads can hit any node
• Examples: Postgres, MySQL, MongoDB, Redis
• Pros: simple, consistent writes, easy to reason about
• Cons: writes capped at one node; failover takes time; follower lag causes read-after-write issues

Multi-leader (master-master):

• Multiple leaders, typically one per region; bi-directional async replication
• Examples: Postgres BDR, MySQL Galera, CouchDB, DynamoDB Global Tables
• Pros: low write latency globally, survives region failure with hot capacity elsewhere
• Cons: conflicts on concurrent writes need resolution; operationally complex

Leaderless (Dynamo-style quorum):

• No leader; coordinator writes to N replicas in parallel, commits when W ack; reads from R replicas, merges
• Examples: DynamoDB, Cassandra, Riak
• Pros: survives multi-node failure, no failover needed, tunable consistency per operation
• Cons: consistency is per-op not global; concurrent-write conflicts still possible

Quorum math — R + W > N

With N=3 replicas, the standard is R=W=2. Read and write sets overlap by at least one node, so reads see the latest write. Tunable: R=1 W=3 for read-heavy, R=W=1 for fastest+eventual, R=W=3 for strict but no failure tolerance.

The single-leader trap — read-after-write

User posts tweet to leader, refreshes, hits a follower that hasn't replicated yet, doesn't see their own tweet. Solutions: read-from-leader for 30s after write; sticky session; pass write LSN as version token, replica waits until caught up; synchronous replication.

Monotonic reads: route the same user to the same follower, so they don't see data appear and then disappear.

Multi-leader conflicts

Resolution strategies:

• Last-write-wins (LWW): timestamp-based; bad because clock skew loses data
• Vector clocks: track causality; concurrent writes surfaced to app code
• HLC (Hybrid Logical Clocks): wall + logical, bounded skew
• CRDTs: data structures that merge mathematically (counters, sets, collaborative-editor sequences)
• Avoid: route writes by partition key so each row only writes to one leader

Sync vs async — orthogonal to topology

• Async: low latency, risk of data loss on leader crash. Default in most relational DBs.
• Sync (all replicas): no data loss but a slow replica blocks every write. Rarely pure-form.
• Semi-sync (one replica must ack): bounded data-loss + bounded latency. Production sweet spot.

Spanner and Raft systems are inherently quorum-sync.

Failure modes

Single-leader: failover via Patroni/Orchestrator; STONITH or fencing for split-brain prevention; recent writes lost if async.

Multi-leader: partition causes conflict storms on heal; mitigation = partition by key.

Leaderless: read repair (write latest back to lagging replicas during reads) + anti-entropy background reconciliation.

Cascade: follower lag → leader WAL grows → leader OOMs disk. Monitor lag and alert early.

Match topology to use case

• Relational with read-scale needs → single-leader Postgres/MySQL with replicas + semi-sync
• Global low-latency writes, low-conflict workload → multi-leader, partition by region
• Max availability + scale, key-value workload → leaderless Cassandra/DynamoDB with R+W>N

Recommendation

Default to single-leader for transactional/relational workloads (Postgres or MySQL with one or two replicas, semi-sync replication, read-after-write via sticky session or LSN token). Reach for multi-leader only when global write latency requires it and you can route by key to avoid conflicts. Use leaderless quorum (Cassandra/DynamoDB) for high-availability key-value workloads where R+W>N gives you tunable consistency per operation. The replication topology determines your CAP/PACELC posture — pick deliberately.