Leader-Follower (Primary-Replica) Replication

Leader-follower replication, also called primary-replica or master-slave replication, is the most common replication architecture in production databases. A single node -- the leader (or primary) -- accepts all write operations. After processing a write, the leader appends the change to a replication log (such as PostgreSQL's write-ahead log or MySQL's binary log) and streams these log entries to one or more follower (replica) nodes. Followers apply the log entries in order, maintaining a copy of the leader's data that can serve read queries. This architecture provides a clear write-ordering guarantee because all mutations flow through a single point of serialization.

The replication log is the heart of the system. In WAL-based (physical) replication, the leader ships the exact byte-level changes to its storage files. This is efficient but ties replicas to the same storage engine version and architecture. In logical (row-based) replication, the leader ships higher-level change records -- insert row X, update row Y, delete row Z -- which are decoupled from the physical storage format. Logical replication enables heterogeneous setups (different PostgreSQL versions, or replicating to a data warehouse) at the cost of slightly higher overhead. MySQL's GTID-based binlog replication uses globally unique transaction identifiers to track replication position, making failover and replica provisioning significantly simpler than older file-position-based approaches.

Failover is the most operationally complex aspect of leader-follower replication. When the leader fails, the system must detect the failure (typically via heartbeat timeouts), promote a follower to become the new leader, and redirect clients to the new leader. This process introduces several risks. If the timeout is too short, transient network glitches can trigger unnecessary failovers (flapping). If the timeout is too long, the system experiences extended write unavailability. The most dangerous failure mode is split-brain: if the old leader comes back online without realizing it has been replaced, two nodes accept writes simultaneously, causing divergent data that is extremely difficult to reconcile. Production systems mitigate split-brain using fencing tokens, STONITH (Shoot The Other Node In The Head), or consensus-based leader election via tools like etcd or ZooKeeper.

Read-after-write consistency is a persistent challenge with leader-follower replication. When a client writes to the leader and then immediately reads from a follower, the follower may not have received the latest change yet, causing the client to see stale data -- effectively losing their own write. Solutions include routing reads of recently-written data to the leader (read-your-writes guarantee), using synchronous replication for at least one follower (semi-synchronous mode), or including a version token with reads so that followers can wait until they have caught up to the required version before responding.

Think of a restaurant kitchen where the head chef (leader) is the only one who decides each dish's recipe and writes it on the order board. Three line cooks (followers) watch the board and replicate each dish exactly as written. Customers can ask any line cook what today's special is (read), but only the head chef can change the menu (write). If the head chef calls in sick, the sous chef (most experienced line cook) takes over -- but there is a brief period of confusion while the other cooks learn who is in charge. If the head chef comes back without knowing the sous chef took over, both might try to change the menu simultaneously, leading to conflicting dishes (split-brain).