Replication

Step 1 Understand it

The problem it solves. One copy of your data is a single point of failure, and one machine can only answer so many reads. You need copies — and then you have to keep them in agreement.

Watch it happen

Picture it

flowchart LR
  W["Writes"] --> L[("Leader")]
  L -->|"synchronous copy"| F1[("Follower 1<br/>another zone")]
  L -.->|"asynchronous copy<br/>(may lag)"| F2[("Follower 2")]
  R["Reads"] --> F1
  R --> F2

The idea

Copies give you availability (another copy takes over when one fails), durability, and more read capacity. In leader–follower replication, all writes go to the leader and the followers copy them; reads can go to followers. Copying can be synchronous (safe but slower) or asynchronous (fast, but followers can lag behind). Multi-leader and leaderless designs allow writes in several places but must resolve conflicts.

How it works, step by step

1. A write arrives at the leader. The leader saves it and adds it to its replication log.
2. Followers read that log and apply the same changes in the same order.
3. Synchronous: the leader waits until a follower confirms before telling the client 'done'. Asynchronous: it replies immediately and the followers catch up.
4. Reads can go to followers to spread the load, but they may be slightly behind.
5. If the leader dies: notice it (missed heartbeats), pick the most up-to-date follower, promote it, and send writes to it.

Analogy

A teacher writes on the main whiteboard and assistants copy it onto boards in other rooms. Students in those rooms may see each update a moment later.

Where the analogy breaks

Assistants copy perfectly and in order. Real followers can lag seconds behind or miss updates during failures, and if the main board breaks, safely choosing a new 'main board' (failover) is tricky.

Example

A user changes their profile name and refreshes, but the read goes to a lagging replica and shows the old name. Fix: 'read your own writes' — send that user's reads to the leader for a short time after a write.

Must-know points

• Leader–follower: simple and common; all writes go through one leader.
• Synchronous: no data loss on failover, but slower writes. Asynchronous: fast, but recent writes can be lost.
• Replication lag causes stale reads; fixes include read-your-own-writes and monotonic reads.
• Failover: detect that the leader is dead, promote a follower, redirect writes. Risk: split brain.
• Multi-leader: writes in several regions; conflicts need rules (last write wins, merging).
• Leaderless (Dynamo-style): quorums with W + R > N.

Common mistakes

• Reading from a replica straight after a write, and being surprised by old data.
• Fully asynchronous replication for data you can't afford to lose.
• Automatic failover with no protection against two leaders (split brain).

Step 2 Go further (free, optional)

Optional. The notes above are written to be enough on their own. These free resources give a second explanation and extra practice.

• Watch

  Distributed Systems lecture series: replication

  Martin Kleppmann, University of Cambridge · free on YouTube

• Watch

  ByteByteGo: database replication explained

  ByteByteGo · YouTube

• Read

  The System Design Primer

  Donne Martin · GitHub, free

Step 3 Practise

Try each exercise yourself first: on paper, out loud or in code. Then open the answer and compare it with yours.

1. ExplainSay it in plain words in under a minute, with no notes.

   Explain leader–follower replication and replication lag with the whiteboard picture.

   Show answer

   A teacher writes on the main whiteboard (the leader). Assistants in other rooms copy every line onto their own boards (the followers), in the same order. All new writing happens on the main board only; students can read any board, which spreads them out (more read capacity), and if the main room floods, one assistant's board becomes the new main board (failover).

   Replication lag is the moment between the teacher writing a line and an assistant copying it. A student in another room may see the old version for a moment. With asynchronous copying, the teacher doesn't wait for the assistants, so the lag can grow to seconds when they're busy; with synchronous copying, the teacher waits for at least one assistant to confirm each line, which is safer but slower.

2. DrawSketch the diagram (or class diagram) from memory.

   Draw a leader with two followers, one synchronous and one asynchronous, and the path of a write.

   Show answer

   The client hears "done" only after the leader has saved the write and the synchronous follower has confirmed it, so a committed write survives losing the leader. The asynchronous follower is updated afterwards; reads sent to it may briefly miss the newest writes.

   textCopy

   Client ── 1. write ──► Leader
                            │ 2. save, add to the log
                            ├──► Follower 1 (synchronous,
                            │      another zone)
                            │ ◄── 3. "saved" ──┘
                            │
   Client ◄── 4. "done" ────┤
                            │
                            └ ─ ─► Follower 2 (asynchronous)
                                     5. catches up later;
                                     may lag behind

3. ApplyUse it in a real design question and say exactly where it fits.

   Users see their old profile right after updating it. Explain why, and give two fixes.

   Show answer

   Why: the update went to the leader, but the next read went to a follower that hadn't copied it yet. Replication is asynchronous, so a follower can be a fraction of a second, or a few seconds, behind. The user sees their old profile and thinks the save failed.

   Fixes:
   1. Read your own writes: for a short time after a user changes something (say 10 seconds), send that user's reads of their own data to the leader. Or always read a user's own profile from the leader; other people's views of it can come from followers.
   2. Read from a follower that has caught up: the write returns its position in the replication log, and the read is only served by a follower at or past that position (otherwise it goes to the leader).

   Also helpful: the app shows the new value straight away from what it just sent (an optimistic update), and pins each user to one follower, so they never see time go backwards between refreshes.

4. Trade-offsSay what it costs, when not to use it, and the alternative.

   Synchronous or asynchronous replication for a payment ledger? For a social feed?

   Show answer

   Payment ledger: synchronous, to at least one follower in another zone. With asynchronous replication, a leader crash can lose the last few committed payments, even though customers were told "paid". That is not acceptable for money. The price is slower writes (each commit waits for a second copy), which is worth paying.

   Social feed: asynchronous. Speed and availability matter more. If a rare failover loses the last second of likes or a post shows up a moment late, almost nobody notices, and the writes stay fast even under huge load.

   A common middle way: one synchronous follower and the rest asynchronous ("semi-synchronous"), so you get no data loss with only one extra wait per write.

Step 4 Interview-ready, then prove it

Your interview answer

About 20 to 40 seconds, said out loud. Practise it until it sounds like you, not like notes.

I'd use leader–follower replication: writes to the leader, reads spread across replicas, with at least one synchronous replica in another zone for safe failover. Screens where users must see their own change straight away read from the leader.

Follow-up questions

Tick each check when you can do it without notes