Leader-Follower Architecture

You’ve probably already met this idea under a different name. Master-slave replication is one of the first scaling tricks people learn:

• One database does the writing, the others copy it and help with reading.
• Leader-follower is the exact same pattern, just with friendlier, clearer names.
• So if you know master-slave, you already know most of this. We’re just going to use the modern words and go a little deeper.

Let’s walk through what changed, what stayed the same, and why teams everywhere lean on this setup.

🎯 Why the Rename

For years everyone called this master-slave. Then the industry slowly moved to leader-follower (and sometimes primary-replica). Here’s the thinking:

• The old words carry an ugly history, so big projects and databases swapped them for terms that feel more respectful.
• The new names are also just clearer about the job. “Leader” tells you who’s in charge, “follower” tells you who’s copying along.
• Nothing about how the system works changed. Same pattern, same behaviour, only the labels are different.

So when you see “primary and replica” in one tool and “leader and follower” in another, don’t get confused. They all mean the same role.

🧩 What is Leader-Follower

Let’s pin down the two roles before we go further. The whole architecture is built on just these:

• The leader is the one node that accepts writes. A write is any change to the data, like adding a row, updating it, or deleting it. All changes go through the leader, nobody else.
• A follower is a copy of the leader. It keeps a near-identical copy of the data and serves read requests, where a read is just asking for data without changing it.
• The act of the leader sending its changes to the followers so their copies stay up to date is called replication.

So picture a small classroom. The teacher writes on the main whiteboard, and a few students copy everything into their own notebooks. If anyone wants to read the notes, they can glance at any notebook. But only the teacher gets to write on the board. That teacher is your leader, the notebooks are your followers.

⚙️ How It Works

Here’s the flow once the system is running. Reads and writes take different paths:

• When a client wants to change data, it sends the write to the leader. The leader saves it, then replicates that change out to every follower.
• When a client wants to read data, it can ask any follower. Since the followers all carry a copy, they can answer reads without bothering the leader.
• This split is the whole trick. One place for writes, many places for reads.

And if the leader ever dies, the system promotes one of the followers to become the new leader. Here’s the picture.

So writes flow down into the leader, copies flow out to the followers, and reads get spread across those followers. Here’s the same split laid out as duties.

🗳️ Failover and Leader Election

Now the scary question. What if the leader crashes? No writes can happen, so the system has to react fast. This recovery is called failover:

• Failover means automatically switching over to a healthy node when the current leader goes down.
• To do that, the system picks one of the followers and promotes it to be the new leader. Promoting just means giving that follower the leader’s job, so it starts accepting writes.
• Choosing which follower becomes the new leader is called leader election. The remaining nodes agree on one of them, and that one takes over.

Once the new leader is chosen, clients send their writes to it instead, and life goes on. Leader election is a deep topic on its own, and you’ll see it again when we cover how distributed systems agree on a single leader.

⚡ Benefits

Why do so many teams reach for this setup? It buys you a few real things:

• Read scaling. Reads usually outnumber writes by a lot. Add more followers and you spread all that read traffic across them, so the system handles way more readers.
• Availability. If the leader dies, a follower steps up, so the database doesn’t just stop. Availability is the system staying usable even when parts of it fail.
• The leader stays focused. Since followers soak up the reads, the leader can spend its energy on writes alone, which keeps writes fast.

So for the very common case of “tons of reads, fewer writes,” this pattern fits like a glove.

⚠️ Trade-offs

It’s not free, though. Every design has a cost, and here’s what you pay:

• Replication lag. Copying data to followers takes a tiny bit of time. So a follower might be a hair behind the leader, and a read from it could return slightly old data. Reading data that’s not the latest is called a stale read.
• Writes still bottleneck on one node. Followers help reads, but every single write goes through the one leader. So this scales reads, not writes.
• Failover adds complexity. Detecting the leader is dead, electing a new one, and pointing clients at it is fiddly to get right, and mistakes here can lose data.

So you’re trading a bit of staleness and some operational work for a lot of read capacity and better uptime. For most apps that’s a great deal.

🧩 Single-Leader vs Multi-Leader

What we’ve described so far has exactly one leader. That’s the common case. But there’s a variation worth knowing:

• Single-leader means one node takes all writes, and that’s what most setups use. It’s simple because there’s never any confusion about who’s in charge.
• Multi-leader means several nodes can accept writes, often one per region so writers nearby get a fast leader. The catch is conflict resolution, where two leaders change the same data at once and the system has to decide which change wins.

So multi-leader can speed up writes across regions, but it brings real headaches. Unless you have a strong reason, start with single-leader.

⚠️ Common Mistakes and Misconceptions

A few things trip people up. Let’s clear them out:

• “Followers can take writes too.” No. In single-leader, only the leader accepts writes. Followers are read-only copies. Sending a write to a follower is an error.
• “Leader election is instant and free.” It isn’t. There’s a real gap while the system notices the leader is gone and agrees on a new one, and writes pause during that time.
• “This scales writes infinitely.” Nope. It scales reads. Every write still funnels through one leader, so write throughput is capped by that single node.

🛠️ Design Challenge

Try this on your own to test yourself.

Imagine Alex runs a news site. Millions of people read articles every minute, but only a handful of editors publish new ones. Sketch a leader-follower setup for it:

• Where do the editors’ writes go?
• Where do the readers’ reads go, and how would you handle a traffic spike?
• The leader server crashes during a busy evening. Walk through what happens next and what the readers might notice.

Think it through end to end. This is exactly the kind of reasoning a system design interview is looking for.

🧩 What You’ve Learned

You can now explain this pattern with confidence. Here’s what you’ve picked up.

• ✅ Leader-follower is the modern name for master-slave, with clearer, more respectful terms.
• ✅ The leader takes all writes, followers replicate the data and serve reads.
• ✅ Failover promotes a follower to leader through leader election when the leader dies.
• ✅ The big win is read scaling and better availability.
• ✅ The costs are replication lag (stale reads), a single write bottleneck, and failover complexity.
• ✅ Single-leader is the common case; multi-leader allows more write spots but adds conflict resolution.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   In leader-follower architecture, which node accepts writes?

   Any follower Only the leader All nodes equally A separate write server
   Check

   Why: Only the leader accepts writes; followers are read-only copies that serve reads.

2. 2

   Why split reads to followers and writes to the leader?

   Because writes are more common than reads Because most workloads read far more than they write, so spreading reads helps Because followers cannot store data Because the leader cannot serve reads
   Check

   Why: Reads usually outnumber writes, so sending reads to followers frees the leader to focus on writes.

3. 3

   What happens when the leader fails?

   All data is lost A follower is promoted to new leader through leader election (failover) Writes go to every follower at once The system shuts down permanently
   Check

   Why: Failover picks one follower through leader election and promotes it so writes can continue.

4. 4

   Does leader-follower scale writes?

   Yes, each follower handles some writes No, every write still goes through the single leader Yes, but only in multi-region setups Only when replication lag is zero
   Check

   Why: It scales reads by adding followers, but the single leader caps write capacity.

Score: 0 / 4 Reset

🚀 What’s Next?

You’ve got the modern view of this pattern. Next, go deeper on the pieces around it.

• Master-Slave Replication revisits the same idea with the classic terms and the replication details.
• Database Sharding shows how to scale writes by splitting data across many nodes, which is the piece leader-follower can’t do on its own.