Databases at Scale

Database Replication

Copying the same data onto multiple machines for availability and read scaling. The central tension is synchronous replication (safe, slow, can block on a dead replica) versus asynchronous (fast, but a crashed leader can lose the last few writes).
  • Leader-follower (single-leader) is the default: all writes go to one leader, reads can be served from followers
  • Synchronous replication guarantees a follower has the data before acknowledging the write; asynchronous acknowledges immediately and replicates in the background
  • Async replication risks read-after-write inconsistency: a client can write to the leader and immediately read stale data from a lagging follower
  • Multi-leader and leaderless replication remove the single point of failure but introduce write conflicts that must be resolved (last-write-wins, vector clocks, application-level merge)
  • Failover (promoting a follower to leader) is the dangerous part — done wrong it causes split-brain, with two leaders both accepting writes
Leader-follower replication and the write path
Async replication acknowledges the client before every follower has caught up

Every replication scheme is a bet about which failure you would rather have. Synchronous replication to all followers means a single slow or unreachable follower stalls every write in the system — a strong consistency guarantee that is also a strong availability liability. Fully asynchronous replication never blocks a write on a follower, but a leader crash right after acknowledging a write can lose it entirely, because it never made it anywhere else. Most production systems compromise: synchronous to one follower ("semi-synchronous"), asynchronous to the rest.

Replication topologies
TopologyWrites go toConflict handlingTypical use
Single-leaderOne leader onlyNone needed — one writerThe default for most OLTP databases
Multi-leaderAny leader, per regionRequired — concurrent writes can conflictMulti-datacenter writes, offline-first apps
Leaderless (quorum)Any replica, client waits for W acksRequired — resolved via versions/timestampsDynamo-style stores (Cassandra, Riak)
Sources
  • Designing Data-Intensive ApplicationsCh. 5 — Replication
  • System Design Interview – An Insider's GuideCh. 6 — Data Store Selection