What a Raft cluster guarantees: majorities, one leader and linearizable reads

What it is

The Raft project page (cited) describes consensus as multiple servers agreeing on values; once a decision is reached it is final. Typical consensus algorithms make progress when any majority of their servers is available (a cluster of five continues with two failed); with more failures they stop making progress but never return an incorrect result. Raft applies this to a replicated state machine: every server keeps a log of commands, and the algorithm ensures that if any server applies a command as the n-th entry, no other server ever applies a different n-th entry. Raft is leader-based; the project page describes it as decomposed into relatively independent subproblems, which the Raft paper names leader election, log replication and safety.

The etcd documentation (cited) states what a client gets: linearizability, the illusion that each operation takes effect at one instant between its invocation and response, so a read returns the most current value. Linearizable requests go through the Raft consensus process; a request can instead be marked serializable to be served locally with lower latency, at the risk of returning stale data.

Why it matters

Few teams implement consensus, but many depend on it indirectly: Kubernetes state in etcd, service discovery, distributed locks, configuration. Knowing the guarantees tells you what to expect during an incident: a cluster that has lost its majority refuses writes and linearizable reads rather than diverging, and a two-member cluster tolerates no failure at all.

How to apply

• Run an odd number of members, three or five; an even number adds no fault tolerance because the majority threshold rises with it.
• Place members in separate failure domains so that losing one domain still leaves a majority.
• Choose the read mode per call: linearizable where a stale answer causes wrong decisions (leases, locks, counters), serializable for high-volume reads that tolerate staleness.
• Keep entries small and the dataset modest; every write is replicated to a majority and made durable before it is acknowledged, so disk sync latency bounds throughput.
• Use conditional writes (compare the current revision, then update) instead of read-then-write from the client; consensus orders the log, it does not make two client calls atomic.

Pitfalls

A timed-out write may still have been committed; retry only with an idempotent operation. A server that was leader may not yet know it has been replaced, which is why leader-based reads need an explicit check and why holders of a lease still need fencing. Losing quorum is an outage of writes, not of data.

Two sites are not enough

Majority survival of a domain failure needs at least three failure domains. Across two sites, three members split two and one lose quorum when the larger site fails, and four split evenly lose it when either fails; no placement helps. With only two sites, choose deliberately: place the majority where the workload runs and accept that losing that site stops writes; add a small third member in a separate location as a tiebreaker, accepting that its round-trip latency now bounds commits; or keep the cluster in one site and use the second as a backup target rather than as a consensus participant.