Single-Leader Replication: One Node to Rule Them All

WHY IT EXISTS Replication was created to solve three core problems: first, increasing read throughput by spreading read queries across multiple machines; second, increasing availability so the system can survive a node failure; and third, reducing latency by placing data geographically closer to users.

THE MENTAL MODEL Think of a project manager (the leader) who is the only person allowed to update the master project plan. Team members (the followers) all have read-only copies. When the manager makes a change, they announce it, and everyone updates their copy in the same order. This ensures everyone is working from a consistent, if slightly delayed, version of the plan. All write requests go to the manager; read requests can go to anyone.

HOW IT WORKS In a single-leader setup, one replica is designated the leader. It is the only node that accepts write operations (like INSERT, UPDATE, DELETE). The leader records these changes in a sequential replication log. The other replicas, called followers, subscribe to this log and apply the changes in the exact same order as the leader. Followers are typically used for read-only queries. This process can be synchronous, where the leader waits for a follower to confirm the write, or asynchronous, where it does not wait, trading durability for performance.

WHEN TO USE IT Use single-leader replication when your application is read-heavy, as you can add more followers to scale out read capacity. It's the standard, well-understood model for many relational databases (PostgreSQL, MySQL) and some NoSQL databases (MongoDB). It provides a straightforward path to high availability: if the leader fails, a follower can be promoted to be the new leader in a process called failover.

WHEN NOT TO USE IT Avoid this model if your application is extremely write-intensive, as all writes must go through a single leader, which can become a bottleneck. It's also less suitable for multi-datacenter deployments where a single leader in one region introduces high latency for writes from other regions. The failover process, while possible, is complex and can lead to data loss or split-brain scenarios if not handled carefully.

ONE CANONICAL EXAMPLE A standard PostgreSQL setup for high availability. There is one primary (leader) database that handles all writes. It streams its Write-Ahead Log (WAL) to one or more standby (follower) servers. These standbys can serve read-only queries. If the primary server fails, a failover process promotes one of the standbys to become the new primary. However, any writes committed to the old primary that hadn't yet been streamed to the newly promoted leader are lost.