Replication

Hop's database now handles 4,000 lookups a second and its CPU sits at 95%. Almost all of that work is reading. What if several machines each held a full copy of the links and shared the reading? That is replication: the same data, kept on more than one server.

The rule

One leader writes, followers copy and serve reads — or many leaders, and conflicts.

Leader-follower (master-slave): one leader accepts all writes. Each change is streamed to followers (replicas), which apply it and serve reads.

• Great for read-heavy systems: add followers to add read capacity.
• If the leader dies, a follower is promoted (fail-over from the last lesson).
• Followers can lag behind, so a fresh write may not be readable from them yet.

Multi-leader (master-master): several leaders accept writes and copy to each other.

• Writes survive the loss of any one leader and can be local to each region.
• Two leaders can change the same row at the same moment. Something must decide who wins — a conflict. That logic is hard to get right.

Replication also protects data: a copy on another machine survives a dead disk. But it is not a backup — a mistaken DELETE is faithfully copied to every replica within seconds.

The shortcut

Ask: "Where are the writes?" Writes in one place and reads everywhere → leader-follower. Writes must be accepted in several places at once → multi-leader, and plan for conflicts.

The trap is expecting followers to add write capacity. Every follower must apply every write, so writes do not spread out — only reads do.

Drills

Answer fast — trust the rule.

Remember

• One leader writes, followers copy and serve reads — or many leaders, and conflicts.
• Shortcut: "where are the writes?" One place → leader-follower.
• Trap: followers add read capacity, not write capacity — and replication is not a backup.