Raft

Raft is a consensus algorithm: a protocol for getting multiple servers to agree on a shared state and to keep agreeing as servers fail and recover. The Raft project describes consensus in exactly those terms, and the algorithm’s stated design goal was understandability, on the view that a protocol people can reason about is one they can implement and operate correctly.

The problem it solves is the one that quorum reads and writes leave open. Overlapping read and write sets ensure a reader can find the newest value, but they do not by themselves produce a single agreed sequence of operations. Consensus does, which is what makes it the foundation for leader election, configuration stores, lock services, and anything else where every participant must see the same decisions in the same order.

Its fault tolerance is stated as a majority: the system continues to operate as long as a majority of servers are available. Which gives the familiar sizing arithmetic — three servers tolerate one failure, five tolerate two — and explains why consensus clusters are odd-sized, since adding an even-numbered member raises the majority threshold without raising the number of failures survived.

The cost is what to weigh in design. Every decision requires a round trip to a majority, so throughput is bounded and latency is bounded by the slowest member of that majority — which is why spreading a consensus cluster across distant regions is usually a mistake rather than an improvement in resilience.

The practical consequence for most architectures is to use consensus deliberately and sparingly: for the small amount of state that genuinely must be agreed, with the bulk of data handled by replication schemes that do not pay this price on every operation.

Where that line falls, and how it relates to quorums and consistency models, is worked through in Replication, Consistency, and Time.