Chapter 14 — Consistency & Consensus
Chapter 14 — Consistency & Consensus
Hey everyone! Welcome to Season 4 — Reliability & Scale! 🙏
In Chapter 09 (CAP) we said systems sometimes trade consistency for availability. But "consistency" isn't one thing — it's a spectrum. And when machines must agree on a decision despite crashes and network chaos, they need a consensus algorithm. This is the deep, brainy heart of distributed systems. We'll keep it simple and visual.
What we will cover:
- The consistency spectrum: strong → eventual
- What eventual consistency really means
- Read-after-write & other useful guarantees
- The consensus problem (agreeing despite failure)
- Quorums: the R + W > N trick
- Raft in plain English
- Interview Questions
1. Consistency Is a Spectrum, Not a Switch
STRONG ◀─────────────────────────────────────────▶ WEAK
consistency consistency
[Strong] every read sees the latest write, always.
Feels like ONE machine. Safe but slower.
→ bank balances, inventory
[Eventual] reads might be stale for a moment, but ALL
copies converge to the same value soon.
Fast & highly available.
→ likes, view counts, DNS, social feeds
┌─────────────────────────────────────────────────────────────┐ │ STRONG: write ₹500 → EVERY reader instantly sees ₹500 │ │ │ │ EVENTUAL: write ₹500 → some readers briefly see the old │ │ value → within ~1s, everyone sees ₹500 │ └─────────────────────────────────────────────────────────────┘
2. Eventual Consistency — Friend, Not Enemy
Beginners hear "eventual" and think "broken." It's not! It's a deliberate trade for speed and availability, and it's everywhere.
You like a photo. Your friend across the world might see the like count update a second later than you. Does anyone care? No. That 1-second window bought massive scale and availability. That's eventual consistency earning its keep.
Useful in-between guarantees
| Guarantee | Promise |
|---|---|
| Read-after-write | You always see your OWN writes immediately (fixes the Ch 07 bug) |
| Monotonic reads | Once you've seen a value, you never see an older one (no going backward) |
| Causal consistency | Cause is seen before effect (you see a question before its answer) |
3. The Consensus Problem
Now the hard part. Multiple nodes must agree on a single value — like "who is the leader?" or "what's the next entry in the log?" — even though nodes can crash and messages can be lost or delayed.
┌─────────────────────────────────────────────────────────────┐ │ CONSENSUS = getting a group of unreliable nodes to agree │ │ on ONE value, reliably. │ │ │ │ Analogy: a group of friends deciding on a restaurant over │ │ a bad phone line where calls keep dropping — yet they must │ │ ALL end up at the SAME place. Harder than it sounds! │ └─────────────────────────────────────────────────────────────┘
Consensus algorithms (Paxos, Raft) power the most critical systems: leader election, distributed locks, config stores like ZooKeeper and etcd (which runs Kubernetes).
4. Quorums — Agreement by Majority
The simplest consensus idea: majority vote. If more than half agree, that's the decision. This gives us the famous quorum formula:
N = total replicas
W = nodes that must ACK a WRITE
R = nodes that must respond to a READ
THE MAGIC RULE: R + W > N
→ guarantees your read set and write set OVERLAP by at
least one node, so a read always sees the latest write.
Example: N=3, W=2, R=2 → 2 + 2 = 4 > 3 ✅
Write reaches 2 nodes; any read of 2 nodes hits at least
one that has the new value. Consistency without contacting
ALL nodes → survives one node being down.
Write to nodes: [A✅] [B✅] [C ] (W=2, C missed it)
Read from nodes: [A✅] [C ] (R=2)
↑ overlap! A has the latest value ✅
5. Raft in Plain English
Raft was designed to be understandable (Paxos is famously confusing). The core idea:
1. LEADER ELECTION
Nodes elect ONE leader by majority vote. Each node waits
a random time, then says "vote for me!". First to get a
majority becomes leader. (Random timers avoid ties.)
2. LOG REPLICATION
All writes go to the LEADER. The leader appends to its
log and replicates to followers. Once a MAJORITY confirm,
the entry is "committed" (safe, permanent).
3. FAILURE
Leader crashes? Followers notice (no heartbeat) → hold a
new election → new leader. The majority rule ensures no
committed data is ever lost.
[ Leader ] ──append "x=5"──▶ [ Follower 1 ] ✅
│ └──▶ [ Follower 2 ] ✅
│ majority (2 of 3) confirmed → COMMITTED ✅
heartbeats keep followers from starting an election
You won't implement Raft in an interview, but knowing "leader election + majority-committed log" shows real depth.
Interview Questions — Quick Fire!
Q: What's the difference between strong and eventual consistency?
"With strong consistency, every read reflects the most recent write — the system behaves as if there's a single copy, which is safe but slower and less available. With eventual consistency, reads may briefly return stale data, but all replicas converge to the same value shortly after. Eventual consistency trades immediate accuracy for speed and availability, which is fine for things like like-counts or feeds."
Q: Is eventual consistency a bad thing?
"Not at all — it's a deliberate trade-off. For data where a brief delay is harmless, like social media likes or view counts, eventual consistency buys much better performance and availability. You only need strong consistency where staleness is dangerous, like account balances or inventory. Choosing the right level per data type is the skill."
Q: What is consensus in distributed systems?
"Consensus is getting a group of nodes to agree on a single value despite failures — crashed nodes, lost or delayed messages. It's needed for things like electing a leader, distributed locks, and keeping a replicated log in sync. Algorithms like Paxos and Raft solve it, and they underpin critical systems like ZooKeeper and etcd."
Q: Explain quorum and the R + W > N rule.
"In a system with N replicas, a write must be acknowledged by W nodes and a read must gather responses from R nodes. If R plus W is greater than N, the read set and write set are guaranteed to overlap on at least one node, so a read always sees the latest write. This gives consistency without contacting every node, and it tolerates some nodes being down."
Q: How does Raft work at a high level?
"Raft elects a single leader by majority vote using randomized timers to avoid ties. All writes go through the leader, which appends them to its log and replicates to followers; an entry is committed once a majority confirm it. If the leader fails, followers detect the missing heartbeat and elect a new leader. The majority requirement ensures committed data is never lost."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| Spectrum | Strong (always latest, slower) ↔ eventual (briefly stale, fast). Pick per data type. |
| Eventual | Not broken — a deliberate scale/availability trade. Everywhere in social systems. |
| Consensus | Unreliable nodes agreeing on one value despite crashes. Powers leader election, locks. |
| Quorum | R + W > N guarantees read/write overlap → consistency with fault tolerance. |
| Raft | Leader election + majority-committed replicated log. Understandable consensus. |
What's Next?
Chapter 15 tackles the architectural debate of the decade: monolith vs microservices. One big app or many small ones? We'll cut through the hype and give you the real trade-offs.
Keep designing, keep scaling! See you in the next one!
Post a Comment