leader-follower pattern
Designate one node as leader; all writes go through it; followers replicate the leader's log. Simple, well-understood, the dominant model for most relational databases and many NoSQL stores. Trade-offs: leader is a write bottleneck and a single point of failure (mitigated by automatic re-election), and followers may serve stale reads.
Designate one node as leader; all writes go through it; followers replicate the leader's log. Simple, well-understood, the dominant model for most relational databases and many NoSQL stores. Trade-offs: leader is a write bottleneck and a single point of failure (mitigated by automatic re-election), and followers may serve stale reads.
symptoms
- need consistent writes across replicas
- want read scaling without write coordination
causes
- multi-leader is hard (conflicts)
- leaderless requires quorums and version reconciliation
fixes
- leader handles writes, replicates to followers
- consensus algorithm for leader election (Raft, Paxos)
- fencing tokens to prevent split-brain
- sync vs async replication trade-off
you might say
- the primary
- fail over to a replica
- read replica