Art of Codeartofcode
Lesson 4 of 17

14. Replication

1
The picture to keep in your head
2
14.1 Why keep copies of the same data?
3
14.2 How does leader-follower replication work?
4
14.3 Should the leader wait for followers before confirming a write?
5
14.4 What is replication lag, and why does it happen?
6
14.5 How do you stop lag from confusing users?
7
14.6 How do you use read replicas in practice?
8
14.7 What happens when the leader fails?
9
14.8 What is split brain, and how is a leader safely chosen?
10
14.9 When would you have more than one leader?
11
14.10 How does leaderless replication work, and what are quorums?
12
Memory card and where the analogy breaks
13
Practice: five levels
14
Interview questions
15
Solutions
16
Sources
17
Code lab
14. Replication

14.3 Should the leader wait for followers before confirming a write?

3 min read+10 XP

At the bank: Head office can tell a customer "your notice is filed" only after a branch confirms it has a copy (slower, but safe if head office burns tonight). Or it can say "filed" immediately and send the copies afterwards (fast, but if head office burns tonight, today's notices are gone).

In the system:

synchronous waits for a follower before confirming; asynchronous confirms immediately and copies later.

Figure: synchronous trades speed for safety; asynchronous trades safety for speed.

  • Synchronous replication: the leader confirms a write only after a follower has it. No confirmed write is lost if the leader dies. But every write waits for a network round trip, and if that follower is slow or down, writes slow down or stop.
  • Asynchronous replication: the leader confirms immediately and followers catch up later. Fast, and followers can't block writes. But if the leader dies, its most recent writes may never have reached any follower, and they're lost when a follower is promoted. In the chapter's code, a leader with 10 writes dies while its follower has 7: promoting the follower loses 3 orders.
  • Semi-synchronous (the common middle ground): wait for one follower, let the others catch up asynchronously. One confirmed copy elsewhere, without waiting for all of them.

Many databases default to asynchronous (PostgreSQL's streaming replication does) and let you turn on synchronous replication for specific standbys or even specific transactions. Choose per data: orders and payments deserve at least one synchronous copy; view counts don't.

Memory code: "Wait for a copy and be safe, or don't wait and be fast."