Designing Data-Intensive Applications
Ch. 5

Leaders and Followers

Leader-based replication funnels all writes through one node and copies them to followers.

Replication keeps copies of data on multiple machines for fault tolerance and read scaling. The simplest scheme designates one leader that accepts writes and broadcasts changes to follower replicas.

Diagram
In practice

PostgreSQL streaming replication sends the WAL from primary to standbys. Amazon RDS Multi-AZ runs synchronous replication within an AZ pair. MongoDB replica sets elect a primary; secondaries tail the oplog. Read replicas on AWS Aurora offload analytics queries from the writer.

WhatsApp at scale

Message history replicates from a primary shard to followers so reads scale globally. All writes funnel through the leader; followers tail the WAL to stay consistent without accepting direct writes.

typescript — Write-ahead log replication
// WhatsApp-style leader → follower replication via write-ahead log
async function replicateWrite(entry: WalEntry) {
  await leader.appendWal(entry);
  for (const follower of followers) {
    follower.streamWal((e) => follower.apply(e)); // async tail of leader log
  }
  return leader.confirmWrite(entry.lsn);
}
Diagram
Key Takeaways
  • One replica is the leader; all writes go to it.
  • Followers replicate the leader's write log and serve read traffic.
  • Synchronous replication waits for follower ack before confirming writes.
  • Asynchronous replication is faster but risks data loss on leader failure.
  • New followers bootstrap by copying a snapshot then tailing the log.
  • PostgreSQL streaming replication, MySQL primary-replica, and MongoDB replica sets all use this pattern.
leaderfollowerPostgreSQLMongoDBreplication logsynchronous replication