Leader and follower

The pattern

Designate one node as the leader (a.k.a. primary/master); all others are followers (replicas/secondaries). Writes go to the leader, which orders them and streams the changes to followers. Reads can come from the leader or, for scale, from followers. It’s the backbone of most replicated databases.

Why elect a leader at all

Coordinating writes across equals is hard — concurrent writes conflict and need reconciliation. A single leader serializes writes into one order, so every follower applies the same changes in the same sequence and converges to the same state. You trade some write throughput (one node funnels writes) for a much simpler consistency story.

What you get

• Consistency — one authority on write order; no write–write conflicts.
• Read scaling — add followers to absorb read load (accepting that follower reads may lag the leader → eventual consistency on replicas).
• Clear failover target — if the leader dies, promote a follower.

Leader election

When there’s no leader (startup) or the leader dies, the cluster must agree on a new one — and crucially, agree on exactly one to avoid split-brain. This is a consensus problem, solved by algorithms like Raft or Paxos, or delegated to a coordination service like ZooKeeper/etcd. The common thread: a candidate needs a majority (quorum) of votes to become leader, which guarantees two leaders can’t both win.

The hard parts to mention

• Failure detection — followers notice the leader is gone via missed heartbeats (next lesson). Too sensitive → needless elections; too slow → long unavailability.
• Split-brain — if a network partition leaves the old leader alive on one side and a new one elected on the other, both accept writes and diverge. Prevented by requiring a majority to lead (the minority side can’t elect or keep a leader) and by fencing the old leader.
• Failover data loss — under async replication, writes not yet shipped to the promoted follower are lost. Semi-sync replication bounds this.

Where it shows up

Almost everywhere stateful: Postgres/MySQL primary–replica, MongoDB replica sets, Kafka partition leaders, Redis replication, and coordination services themselves. Single-leader is the default; multi-leader and leaderless (quorum-based) are the alternatives when you need write availability or locality the leader can’t give.

The interview cue

When you replicate a store, state the model explicitly: “single leader for writes, followers for read scaling; on leader failure a follower is promoted via a quorum election, and I’d note the split-brain risk and the async-replication data-loss window.” That one sentence ties together replication, quorums, heartbeats, and failover.