Replication: leader-based vs. leaderless

Storing the same data on multiple machines (replicas) serves two goals at once: availability (if one machine dies, another already has the data) and read scalability (many machines can serve read traffic in parallel). The hard part isn't deciding to replicate — it's deciding how writes propagate between replicas without the copies drifting apart or contradicting each other.

One replica is designated the leader; all writes go to it first, and it propagates the change to the other followers. Reads can typically go to any replica, trading some staleness risk (a follower that hasn't yet received the latest write) for spreading read load across many machines.

This design has one obvious advantage: writes are trivially ordered, since they all pass through a single leader, which can simply apply them in the order it received them. The obvious cost: the leader is a single point of coordination — if it fails, something has to detect that and promote a new leader (lesson 9 covers failure detection; a botched promotion can briefly produce two leaders at once, called split-brain, which is exactly the kind of failure consensus algorithms in lessons 7–8 exist to prevent).

Instead of one designated leader, any replica can accept a write, and the system uses quorums to keep reads and writes consistent enough: a write is considered successful once acknowledged by W out of N replicas, and a read queries R replicas and reconciles their answers. Choosing W and R such that W + R > N guarantees every read overlaps with at least one replica that has the latest write.

This avoids a single point of coordination entirely — any replica being unreachable doesn't block writes the way a dead leader does. The cost: without a single leader deciding write order, two clients can write to the same key at genuinely the same time with neither aware of the other, producing exactly the concurrent-write conflict that vector clocks (lesson 3) exist to detect and surface.

Leader-based replication buys simple write ordering at the cost of a single point of coordination that needs failure-handling; leaderless replication buys resilience against any single node failing at the cost of needing an explicit mechanism (quorums, vector clocks, conflict resolution) to handle writes that genuinely raced each other.

PostgreSQL's standard replication, MySQL's primary-replica setup, and most traditional relational databases are leader-based. Amazon's Dynamo, Riak, and Cassandra (in its typical configuration) are leaderless, explicitly designed for the "always accept a write, resolve conflicts later" AP philosophy that System Design's CAP theorem lesson names directly.