Consensus Protocols

When multiple nodes must agree on a single value, you need consensus. Raft is the right answer 95% of the time.

How It Works

Distributed systems need consensus when multiple nodes must agree on a value — who's the current leader, what's the committed transaction order, what's the latest config. Consensus protocols like Raft and Paxos guarantee: if a majority of nodes survive, the system agrees; if a minority is partitioned off, they can't make conflicting decisions. Raft has replaced Paxos in most new systems because it's simpler to implement and reason about — leader election, log replication, and safety properties are all explicit. When you hear "strong consistency," "linearizable writes," or "exactly-once processing" in a design, consensus is usually running underneath. In interviews, don't invent your own consensus protocol — cite Raft or "a Raft-like consensus layer."

Real-World Example

etcd (Kubernetes' backing store) uses Raft to replicate cluster state across 3 or 5 nodes. Every write — creating a pod, updating a config, modifying a secret — goes through Raft consensus. The leader proposes, followers vote, and only committed values become readable. This is why kubectl apply has predictable semantics even during node failures. CockroachDB, Consul, and TiKV also use Raft as their foundational consistency layer. If you're designing a system where a wrong answer is worse than no answer (finance, inventory, coordination), sketch a Raft group where the critical state lives.