Distributed Systems
Raft Consensus Explained
Raft Consensus Explained
08:50#consensus#raft#leader-election#distributed-systems
We build Raft from scratch: why distributed systems need consensus, what linearizability requires, and how Raft achieves it with a leader, a log, and a term clock. Every decision is justified by the failure it prevents.
Topics covered:
- The problem: why "just replicate" doesn't work without total order
- Leader election: why a random timeout prevents livelock
- Log replication: how the leader enforces ordering across followers
- The election restriction: why the leader must have the most up-to-date log
- Commit rules: what "committed" means and why a majority is required
- Safety invariants: leader completeness and election safety
- Network partitions: how Raft stays consistent when the network splits
- Performance: the cost of synchronous replication and how multi-raft scales
Related articles
distributed systems
Consensus Algorithms Aren't About Agreement
Raft, leader election, and split-brain — what consensus actually solves and what it doesn't.
5 min readRead
distributed systems
What Is a Distributed System, Really?
A system where the failure of a computer you didn't even know existed can render your own computer unusable. How to recognize a distributed system you never asked for.
3 min readRead
distributed systems
Eventual Consistency Is a Spectrum
Strong, causal, read-your-writes — the consistency zoo and when each model is the right engineering choice.
4 min readRead
Depth, delivered weekly
One technical dispatch a week — articles and episode notes before they go public.
One technical dispatch per week. No noise.