Skip to content
Optimal Lab

System design · interactive

Replication and stale reads

One database becomes three: a leader takes the writes and copies them to two followers, which serve reads. The copy takes time. Change your name from “Sam” to “Sara”, read it back, and see what you get.

Client

got OK

Leader

name = Sara

Follower 1

name = Sam

Follower 2

name = Sam

Tick 0: The leader writes “Sara” and confirms at once. The followers still say “Sam”.

Leader confirms the write

Your next read goes to

tick 0

Step 1 of 5

  1. 1

    The write goes to the leader

    Only the leader accepts writes, so there is one order of changes for everyone to copy.

    UPDATE users SET name = 'Sara' WHERE id = 7

  2. 2

    The leader confirms

    Async: right away, so writes are fast but a crash can lose them. Semi-sync: after one follower has it, which survives a leader crash but adds a round trip to every write.

    The client has its OK.

  3. 3

    Followers copy the change

    Each follower replays the leader's log in order. How far behind it is, is the replication lag: usually milliseconds, sometimes seconds under load.

    leader Sara · f1 Sam · f2 Sam

  4. 4

    The client reads it back

    A follower that hasn't caught up returns the old value. “Read your writes” sends a user's own reads to the leader for a short time after they write.

    Not read yet.

  5. 5

    Failover promotes a follower

    A follower becomes the new leader. Whatever the old leader confirmed but never shipped is gone. That is the price of async replication.

    Turn on the crash to see it.

In production

Tools and technologies

Every major database ships leader–follower replication; the knobs are sync vs async and where reads go.

Not tied to one language — use these names when you search docs or design a system.