Replication
Replication keeps copies of the same data on several machines. It improves availability and read capacity, but keeping copies in step raises hard questions.
Why replicate
Replication serves three goals: high availability, so the database keeps working if one machine fails; read scaling, spreading read queries across copies; and lower latency, placing copies near users in different regions. It also protects against losing data when a disk or server dies, though it is not a substitute for backups, since mistakes replicate too.
Leader-follower replication
In single-leader replication, one node, the leader or primary, accepts all writes and sends a stream of changes, often its write-ahead log, to followers or replicas, which apply them in order. Reads can go to any replica. PostgreSQL streaming replication, MySQL replication, and many cloud databases work this way.
Synchronous and asynchronous
With synchronous replication, the leader waits until a follower confirms a change before acknowledging the commit, so the data survives the leader's loss, at the cost of higher latency and stalls if the follower is slow. With asynchronous replication, the leader acknowledges immediately and followers catch up later, which is faster but can lose recent commits if the leader fails. Many systems use one synchronous follower and the rest asynchronous.
Replication lag
Asynchronous followers can lag behind the leader by milliseconds or, under load, seconds or more. A user who updates a profile and immediately reloads from a lagging replica may see the old version. Guarantees such as read-your-writes, reading one's own updates from the leader, and monotonic reads, always reading from the same replica, hide lag from users.
Failover
If the leader fails, a follower must be promoted to leader, clients redirected, and the old leader prevented from accepting writes if it returns. Automatic failover is fast but risky: a network glitch might cause two nodes to believe they are leader, a split brain, which can corrupt data. Fencing and consensus-based coordination tools prevent this.
Multi-leader and leaderless replication
Multi-leader replication allows writes at several leaders, such as one per data centre, improving local write latency but creating conflicts when the same record is changed in two places; conflicts must be resolved by rules such as last-write-wins or custom merging. Leaderless systems, inspired by Amazon's 2007 Dynamo paper and used by Cassandra, send writes and reads to several replicas at once.
Quorums
In leaderless systems with n replicas, a write is sent to all and succeeds when w acknowledge; a read queries r replicas and takes the newest value. If w + r > n, every read set overlaps every write set, so reads see the latest successful write. A common choice is n = 3, w = 2, r = 2, tolerating one unavailable replica for both reads and writes.
Worked example
A shop uses one leader in Frankfurt and asynchronous followers in Virginia and Singapore. A customer in Singapore updates an address; the write goes to Frankfurt, about 160 milliseconds away. Reads served by the Singapore follower are fast but might be a second behind, so the checkout page reads the customer's own address from the leader (read-your-writes), while product browsing uses the nearby follower.
Key takeaways
Replication provides availability, read scaling, and lower latency, but not protection from bad writes. Single-leader replication streams the leader's changes to followers. Synchronous replication protects commits at a latency cost; asynchronous is faster but may lose recent writes. Replication lag requires guarantees such as read-your-writes and monotonic reads. Failover promotes a follower but risks split brain without fencing. Multi-leader replication creates write conflicts; leaderless Dynamo-style systems use quorums, where w + r > n ensures reads overlap the latest writes.
Flashcard
Copies of data on several machines
Check your understanding
A leaderless store has n = 5 replicas. Which choice of write quorum w and read quorum r guarantees reads overlap the latest successful write?