Topic 13.8
Distributed Consensus (Raft, Paxos)
In one line
The problem behind 'everyone agrees on the same order': Raft and Paxos, and why you almost always use etcd/ZK/Raft behind a library.
Think of it like this
Several people in different cities who've never met, on separate phone calls with no way to hear each other directly, needing to unanimously agree on ONE decision without a mistake — even if some phone lines cut out mid-conversation.
Key ideas
- 01
Consensus = getting N nodes to agree on a value/order despite failures — the foundation of replicated state machines.
- 02
Raft: leader-based, understandable — terms, log replication, commit indexes, leader election by timeout + votes.
- 03
Raft's readable guarantees: past leader's committed entries survive; one live quorum elects a leader.
- 04
Paxos: older, more general, famously hard to implement — interviews only want the high-level purpose + where it's weaker (no single leader, harder progress).
- 05
You implement via libraries: etcd (Raft), Zookeeper (Zab), Consul — never hand-roll consensus.
- 06
Applications: replicated config/registry, leader election, distributed locks, and the commit log itself.
- 07
Interview sentence: 'I'd use etcd's Raft for the consensus pieces — implementation is a solved problem, my job is using it correctly.'
Explain without notes
Why is 'use Raft for the registry' often the RIGHT answer instead of 'implement leader election from scratch'?
Practice
Draw the Raft terms/commit flow: how a client write becomes a committed log entry, and where a leader crash lands.
Trade-offs
- ↔
Consensus costs a quorum round-trip and stalls under partitions — that's the CAM price of strong agreement.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I know when to consume Raft (via etcd/ZK) rather than build it, and can explain why.