Leader-follower replication, also called primary-secondary or master-standby, is the most common way to replicate a database. One node is designated the leader and is the only node that accepts writes; it then streams its changes to one or more followers, which apply the changes and serve read-only queries. PostgreSQL describes the roles directly: “Servers that can modify data are called read/write, master or primary servers. Servers that track changes in the primary are called standby or secondary servers.”
MongoDB’s replica sets work the same way. “The primary node receives all write operations” and “records all changes to its data sets in its operation log, that is, the oplog. The secondaries replicate the primary’s oplog and apply the operations to their data sets such that the secondaries’ data sets reflect the primary’s data set.” Because every write funnels through one node, the leader always has a single, authoritative ordering of writes, which makes strong consistency on the leader simple to reason about.
The scheme also distinguishes how much a follower can do. PostgreSQL notes that “a standby server that cannot be connected to until it is promoted to a primary server is called a warm standby server, and one that can accept connections and serves read-only queries is called a hot standby server.” Hot standbys add read throughput by serving queries; warm standbys exist purely as a backup ready to take over.
The weakness of the scheme is that write availability depends on the leader. If the leader fails, no writes can proceed until a follower is promoted to take its place, a process called failover. MongoDB automates this with elections: when a primary stops communicating “for more than the configured electionTimeoutMillis period (10 seconds by default), an eligible secondary calls for an election to nominate itself as the new primary.” Failover is the moment where leader-follower systems are most fragile, and doing it safely is what makes consensus and quorums necessary.