Leader Election Explained

Table of Contents +

Picture a system with a bunch of machines running the same code. We call each machine a node, which is just one computer in the group. Here’s the situation:

All the nodes are basically equal. Same software, same job, no one is special.
That sounds nice and fair, right? But it actually causes a problem.
For some jobs, you need exactly one node to be in charge. If everyone tries to decide at once, you get chaos.

So how does a group of equal machines agree on who’s the boss? That’s what this lesson is about. We’ll keep it beginner-correct: not dumbed down so much it becomes wrong, but no jargon dumped on you either.

🎯 Why You Need a Leader

Let’s start with the pain, because that’s what makes this click. Imagine three nodes all storing the same data, and a write request comes in:

A write means changing the data, like “set Alex’s balance to 100”.
Now two writes arrive at almost the same time. One says set balance to 100, the other says set it to 50.
If each node decides the order on its own, node A might apply 100 then 50, while node B applies 50 then 100. Now they disagree on the answer.
That’s a conflict, and conflicts are exactly what breaks a system that’s supposed to be consistent.

The fix is simple to say: let one node decide the order for everyone. Here’s the idea:

One node becomes the leader. Every write goes through it first.
The leader puts the writes in a single order and tells the others to follow that same order.
Now everybody ends up with the same data, because they all followed one boss instead of arguing.

So a leader isn’t there to do more work. It’s there to coordinate, which means making sure everyone acts in one agreed order instead of stepping on each other.

👑 What is Leader Election

Okay so we need one node to be the leader. But who picks it? Nobody hands out the crown from outside. The nodes have to sort it out themselves.

Leader election is the process where the nodes pick one of them to act as the leader, also called the coordinator.
The leader does the coordinating job we just talked about. The rest become followers.
A follower is a node that takes orders from the leader instead of making decisions on its own.

Here’s a clean way to remember who does what.

Role	What it does	In plain words
Leader	Decides the order of writes, coordinates the group, sends out heartbeats	The boss who makes the calls
Follower	Copies what the leader decides, answers reads, watches for the leader’s heartbeat	The team that follows along
Candidate	A follower that thinks the leader is gone and asks others to vote for it	Someone running for boss

So at any moment there’s one leader and many followers. And when something goes wrong, a follower can turn into a candidate and try to take over. That’s coming up next.

⚙️ How It Works

The big question is: how do followers even know the leader is alive? They can’t read its mind. So the leader keeps checking in.

A heartbeat is a small “I’m still alive” message the leader sends to the followers, over and over on a timer.
As long as the followers keep getting heartbeats, they relax. The boss is fine, nothing to do.
If the heartbeats stop coming for a while, the followers assume the leader is dead or unreachable. Now it’s time to pick a new one.

When that happens, the nodes run an election. The most common way is a vote:

A follower notices the silence and becomes a candidate. It asks every other node, “vote for me to be leader.”
Each node votes for the first candidate that asks, then waits.
To actually win, a candidate needs votes from a majority of the nodes. Majority just means more than half.

Why more than half? Because that’s how you avoid two winners. Here’s the trick:

If you need more than half the votes to win, only one candidate can ever cross that line at a time. There aren’t enough nodes for two of them to both get a majority.
This majority-agreement idea is called consensus, which just means the nodes reaching a shared decision they all accept.
Algorithms like Raft work exactly this way, and tools like ZooKeeper and etcd use the same majority idea inside.

Here’s the whole flow from a healthy leader to a brand-new one.

Why a majority and not just any node

If we let any node grab the crown the moment it felt like it, two nodes could grab it at the same time. Requiring more than half the votes makes that impossible, because both can’t have a majority at once. That one rule is what keeps the group sane.

🔄 When the Leader Fails

This is the part that makes leader election worth the trouble. A leader will fail someday. Maybe it crashes, maybe its network drops. The system has to keep going anyway.

The followers stop getting heartbeats, so they know something’s wrong.
They run an election and pick a new leader using that majority vote we just saw.
The new leader takes over the coordinating job, and the work continues like almost nothing happened.

This automatic “leader dies, a new one takes over” behavior has a name:

It’s called failover, which means handing the job to a healthy node when the current one goes down.
The whole point is uptime. Users keep getting served while the cluster quietly fixes itself in the background.
There’s a short pause during the election, sure. But it’s seconds, not a dead system, and that’s a great trade.

⚠️ The Danger: Two Leaders

Now here’s where it gets scary, and it’s the thing interviewers love to poke at. What if the old leader didn’t actually die? What if the network just split in half?

A network split, also called a partition, means the nodes get cut into two groups that can’t talk to each other.
The old leader is alive and fine on one side. But the other side can’t hear its heartbeats, so they think it’s dead and elect a new leader.
Now you’ve got two leaders at once, each taking writes, each thinking it’s the only boss. Their data drifts apart and you get a mess.

This is the famous split-brain problem, and it’s exactly why we insist on a majority. A group with fewer than half the nodes can’t elect a leader, so only one side can keep running. We’ll go deep on this in its own lesson, linked at the bottom.

🌍 Where It’s Used

This isn’t theory you’ll never touch. Leader election runs under a lot of systems you already use:

Replicated databases pick one node as the primary. The primary takes all writes and the others copy it, which is the leader-follower setup we described.
Kafka has a controller, which is one broker elected to manage the cluster. If it dies, another broker gets elected.
ZooKeeper and etcd are coordination tools whose entire job is helping clusters agree on things, and electing a leader is the heart of how they do it.
Any leader-follower or primary-replica design you read about is leaning on leader election somewhere underneath.

So when you see “primary,” “master,” or “controller” in a system, that node almost always got there through an election like the one above.

⚠️ Common Mistakes and Misconceptions

A few ideas trip people up the first time. Let’s clear them out:

“Any node can just declare itself leader.” No. Declaring yourself leader means nothing if the others don’t agree. You have to win a majority of votes, and that’s the whole safety mechanism.
“Election is instant.” It isn’t. There’s a real gap while followers notice the missing heartbeats and then vote. During that window there’s no leader, and writes may have to wait.
“There’s no risk of two leaders.” There absolutely is, if you design it loosely. A network split can produce two leaders, the split-brain problem, which is why the majority rule exists.

🛠️ Design Challenge

Try this one on your own to test yourself.

You have five nodes running a replicated database with one leader. A network split cuts them into a group of three and a group of two. Walk through what should happen. For example:

Which side is allowed to elect a leader, and why?
What should the side of two nodes do when it can’t reach a majority?
What happens to writes sent to the smaller side during the split?

Think it through, then compare your answer to the majority rule above. This is exactly how you’d reason about availability and safety in a real interview.

🧩 What You’ve Learned

You can now explain how a group of equal machines agrees on a boss. Here’s what you’ve picked up.

✅ Some jobs need one node to coordinate, so the group avoids conflicts like writes applied in different orders.
✅ Leader election is the process where nodes pick one of them as the leader, and the rest become followers.
✅ Followers watch the leader’s heartbeats, and run a majority vote (consensus) to elect a new leader when those stop.
✅ When the leader fails, the group elects a new one and keeps working, which is called failover.
✅ A network split can create two leaders, the split-brain problem, which the majority rule is designed to prevent.
✅ Replicated databases, Kafka controllers, ZooKeeper, and etcd all rely on leader election underneath.

Check Your Knowledge

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

🚀 What’s Next?

You’ve got the core idea down. Next, go deeper on the two topics this one kept pointing at.

Split Brain Problem digs into how two leaders happen and the tricks used to stop the damage.
Consensus Algorithms Overview shows how nodes reach agreement safely, including how Raft handles elections in detail.

Get those two under your belt and you’ll have a solid grip on how distributed systems stay consistent and available at the same time.

Previous Consensus Algorithms Overview Next Distributed Locks Explained

Share & Connect

Share on LinkedIn