30-Second Glance
- One leader takes all writes; followers async-replicate from its replication log and absorb read traffic.
- Great fit for high read-to-write workloads: e-commerce product pages, CMS articles, social feeds.
- A recovered follower resumes from its last log position — no full resync needed.
- Leader failure is the hard part: async heartbeats can't tell crash from network partition, unreplicated tail writes can be lost, and partitions cause split brain with two "leaders".
- Fix for leader ambiguity is distributed consensus; if you need write throughput instead, look at multi-leader.
Used in: Dynamo DB
How single leader replication works?
- Write Operations:
- User writes to the leader node, which then processes and update it's local storage.
- Replication to Followers:
- The leader asynchronously replicates the changes to the follower nodes.
- Each follower updates its data store to reflect the changes made by the leader.
- Read Operations:
- Read requests can be handled by either the leader or the followers.
- This helps in load balancing as followers can handle read traffic, reducing the load on the leader.
Use Cases
- E-commerce Websites: High read-to-write ratio where product details (reads) are accessed frequently, but updates (writes) are less frequent.
- Content Management Systems: Articles or posts are read by many users, but written by fewer users.
- Social Media Platforms: Posts and comments are frequently read by users, but writes are less frequent compared to reads.
Let's look at Failure Scenarios:
1. Follower goes down.
- Leader sends replication logs to every follower.
- So, when a follower goes down and comes back up Leader can send the data from the last seen position in the follower's replication log.
2. Leader goes down has multiple scenarios.
Scenario 1: Leader unable to contact with it's followers.
Leader might not be able to communicate with some followers due to some network issue but since the calls are asynchronous so there's no way to know if leader is alive and well. In asynchronous communication, there’s no immediate feedback mechanism to know if the leader is actually down or if it’s a network partition issue. This can cause uncertainty among the followers.
Scenario 2: Writes lost due to leader failure.
Last write: , was written to the replication log.
Scenario 3: Split brain
- Occurs when network partitions lead to multiple nodes believing that they're leader.
- This can cause data inconsistencies and conflicts due to writes coming to followers from multiple leaders! Wtf.
To fix this we need Distributed Consensus!
Conclusion:
Simple, easy to modify the existing DB to add replicas. Easy to fix if nodes fail down. More read throughput.
But if we want more write thoughtput?? MultiLeader Replication - chaos.
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| Reads from followers | Offloads leader, high read throughput | Followers may lag; stale reads | Read-heavy pages like product details and posts |
| Reads from leader | Always fresh | Loads the write bottleneck | Read-your-write or critical reads |
| Async follower replication | Fast writes; simple to bolt onto an existing DB | Lost tail writes on leader crash; split brain on partition | Default single-leader setup in the note |
| Sync follower replication | No lost writes | Slow writes; availability hit if a follower stalls | Durability-critical writes only |
Interview One-Liners
Q: How does single-leader replication handle writes vs reads? A: Writes go to the leader and async-replicate to followers; reads can be served by leader or followers for load balancing.
Q: What happens when a follower goes down and returns? A: The leader replays its replication log from the follower's last seen position.
Q: Why can't followers reliably detect a dead leader? A: Replication is asynchronous with no immediate feedback, so a silent leader is indistinguishable from a network partition.
Q: What write-loss scenario does the note show? A: A tail write (e.g. value 80) sitting only in the dead leader's replication log never reaches followers.
Q: What is split brain and what fixes it? A: A partition makes two nodes both believe they are leader and accept conflicting writes; the note points to distributed consensus as the fix.
Q: When do you outgrow single-leader? A: When the leader becomes a write-throughput bottleneck — then consider multi-leader.