Leader-follower replication and lag

Distributed systems Mid-level Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Order the steps

Order what happens during an asynchronous commit and failover.

  • Leader acknowledges the commit
  • Client's acknowledged write is gone
  • Client commits on the leader
  • Leader crashes before shipping that WAL
  • Follower is promoted

Choose an answer, then open Show answer below to check it.

Show answer

Answer: C A D E B

  1. Client commits on the leader The leader writes WAL locally.
  2. Leader acknowledges the commit Async: it doesn't wait for followers.
  3. Leader crashes before shipping that WAL The follower never received the record.
  4. Follower is promoted It becomes the new leader without that commit.
  5. Client's acknowledged write is gone The cost of async replication.

30-second answer

All writes go to the leader, which streams its change log to followers; reads can be served by followers. With asynchronous replication a follower can be seconds behind, so a user may not see their own write, see newer data on one request and older on the next, or see an answer before its question. Synchronous replication to at least one follower avoids losing acknowledged writes on failover but adds latency to every commit.

Practise saying it · 35 s. No recording, just a timer

Explain replication lag.

Say your answer out loud, then check which of these points you covered:

  • Leader takes writes
  • Followers replay the log
  • Lag causes stale reads
  • Sync vs async trade-off
  • Failover can lose writes

Deep dive

PostgreSQL streams WAL; synchronous_standby_names with synchronous_commit = on makes commits wait for a standby.

Measure lag: pg_stat_replication.replay_lag on the primary.

Failover with async replicas can lose the last acknowledged writes; that's the price of not waiting.

Multi-leader and leaderless setups accept writes in several places and must resolve conflicts.

Common mistakes

  • Sending reads that follow a write to a replica.
  • Promoting a lagging replica without knowing what's lost.
  • Running long analytics queries on a hot standby and getting cancelled by replay conflicts (or bloating the primary with hot_standby_feedback).

Senior take & follow-ups

Describe the flow, list the three lag anomalies, and contrast sync vs async on failover.

Follow-up questions

Think of your answer first, then open the hint.

  1. How do you avoid losing writes on failover?

    Show hint

    Synchronous replication to at least one standby, or quorum commit.

  2. Why might a follower cancel a query?

    Show hint

    Replaying WAL needs to remove rows the query still needs.

Related questions

Suggest a fix if something here is wrong or out of date.