Raft

Raft is a consensus algorithm for keeping a replicated log consistent across a cluster of servers, introduced by Diego Ongaro and John Ousterhout as a deliberately understandable alternative to Paxos. It elects a single leader that accepts writes and replicates them to followers, so a majority of nodes always agree on the same ordered sequence of state changes even when machines fail. Raft is the quiet machinery underneath many of the systems that API infrastructure actually runs on.

• Leader election - A cluster elects one leader that owns all client writes; if it dies, the remaining nodes vote in a new one.
• Log replication - The leader appends entries and replicates them to followers, committing only once a majority acknowledges.
• Safety through majorities - A cluster of 2f+1 nodes tolerates f failures while never returning divergent, conflicting state.
• Understandability by design - Raft was engineered to be teachable and implementable, which is why it spread so quickly.

In practice, most API teams never touch Raft directly, but they depend on it constantly. It underpins etcd (and therefore Kubernetes), Consul, TiKV, CockroachDB, and other coordination and storage layers that back modern API platforms, holding service discovery, configuration, and leader locks consistent. When an API gateway, control plane, or config store promises strong consistency, Raft is very often the algorithm making that promise true, which makes understanding its majority-quorum failure model useful for anyone reasoning about the availability of the systems behind their APIs.