{"post":{"slug":"raft-consensus-explained-2026","title":"Raft Consensus: How a Cluster Agrees on Anything","excerpt":"Several machines must agree on a sequence of operations while some of them fail and the network drops messages. Raft solves that, and understanding it explains most distributed database behaviour.","category":"code","date":"January 13, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">S</span>everal machines need to agree on an ordered sequence of operations. Some will fail. The network will drop and delay messages. Two of them must never both believe they are in charge.\n\nConsensus algorithms solve this, and Raft is the one most modern systems use because it was designed to be understandable — which matters, because the operational behaviour of a great many distributed databases follows directly from it.\n\n## What changed in 2026\n\n- **It remained the default choice.** Raft continued to underpin most new distributed data systems.\n- **Election tuning got attention.** Balancing fast failure detection against spurious elections became a recognised operational concern.\n- **Multi-region deployments exposed the latency cost.** Cross-region consensus proved expensive enough to shape topology decisions.\n- **Witness and learner nodes spread.** Non-voting members that help with placement without affecting quorum arithmetic became common.\n\n## The two mechanisms\n\n**Leader election.** Nodes start as followers. If a follower hears nothing from a leader for a timeout, it becomes a candidate and requests votes. A candidate receiving votes from a majority becomes leader. Randomised timeouts prevent every node becoming a candidate simultaneously.\n\n**Log replication.** All writes go to the leader, which appends to its log and sends the entry to followers. Once a majority have written it, the entry is committed and applied. The leader tells followers, which apply it too.\n\nEverything operationally interesting follows from those two.\n\n## Why writes do not scale with cluster size\n\nAll writes go through the leader. Adding nodes adds replicas, not write capacity — and each additional node is another follower the leader must send entries to.\n\nSo a larger cluster does not write faster. It tolerates more failures and can serve more reads if the system allows follower reads.\n\n| Nodes | Majority | Failures tolerated |\n| --- | --- | --- |\n| 3 | 2 | 1 |\n| 4 | 3 | 1 |\n| 5 | 3 | 2 |\n| 6 | 4 | 2 |\n| 7 | 4 | 3 |\n\nNotice that even numbers gain nothing. Four nodes need three for a majority and tolerate one failure — identical to three nodes, with an extra machine to run and an extra follower to replicate to. **Odd sizes only.**\n\n## Why a minority cannot proceed\n\nThe majority requirement is what prevents split brain. If a network partition separates two nodes from three, only the side with three can elect a leader and commit writes. The minority side has a leader that cannot get majority acknowledgement, so it accepts nothing.\n\nThat is correct and it means **a minority partition is unavailable for writes**. Clients on that side see failures until the partition heals. This is the consistency-over-availability choice, per [CAP theorem explained](/blog/cap-theorem-explained-2026), and it is not configurable — it is what consensus means.\n\n## Elections cost availability\n\nWhen a leader fails, followers wait out their election timeout, then elect a new leader. During that window there is no leader and no writes are accepted.\n\nThe timeout is a genuine tradeoff. Short timeouts detect failure quickly and cause spurious elections when the network is briefly slow — and a spurious election is itself a brief outage. Long timeouts avoid that and extend the unavailable window after a real failure.\n\nThe practical consequence: a Raft-based system has brief write unavailability whenever the leader changes, whether from failure, a rolling restart, or a network blip. Planning around that means retry logic in clients rather than assuming continuous availability.\n\nCross-region deployments make this worse. Every write waits for majority acknowledgement, so if the majority spans regions, every write pays a cross-region round trip. This frequently pushes teams toward keeping a voting majority within one region and using non-voting replicas elsewhere.\n\n## Common mistakes\n\n- **Even-numbered clusters.** Extra cost, no extra fault tolerance.\n- **Expecting writes to scale with nodes.** They do not; all writes go through the leader.\n- **Election timeouts too short.** Spurious elections under normal network variance.\n- **A voting majority spanning high-latency links.** Every write pays the round trip.\n- **No client retry logic.** Elections produce brief write failures.\n- **Assuming a minority partition stays available.** It cannot, by design.\n- **Two-node clusters.** A majority of two is two; one failure stops everything.\n\n## FAQ\n\n**Can I read from followers?**\nDepends on the system. Follower reads may return slightly stale data unless the implementation provides a mechanism to ensure currency. Where offered it is a useful way to scale reads.\n\n**How long is an election?**\nTypically a small number of seconds, governed by the timeout configuration. It is brief and not instantaneous, and clients must tolerate it.\n\n**Is Raft the same as Paxos?**\nThey solve the same problem. Raft was designed for understandability, with explicit leader election and log replication, which is why it dominates newer implementations.\n\n**What are witness nodes?**\nMembers that participate in voting without storing full data, used to establish a majority in a third location cheaply. Useful for two-region deployments needing a tiebreaker.\n\n## Where to go next\n\nFor the consistency model consensus provides, read [CAP theorem explained](/blog/cap-theorem-explained-2026). For the leaderless alternative, [quorum reads](/blog/quorum-reads-explained-2026), and for the replication mechanics, [synchronous replication](/blog/synchronous-replication-2026).","hue":306,"metaTitle":"Raft Consensus: How a Cluster Agrees on Anything","metaDescription":"How Raft elects a leader and replicates a log to reach agreement, why majorities matter, and what elections cost in availability.","keywords":["raft consensus","leader election","distributed log replication","majority quorum","split brain prevention","consensus algorithm","cluster availability","distributed systems 2026"],"tldr":["**One leader accepts writes and replicates them** — which is why write throughput does not scale with cluster size.","**A majority must acknowledge before a write commits** — so a minority partition cannot make progress.","**Elections cause brief unavailability** — a leader failure means seconds of no writes.","**Odd cluster sizes are what you want** — four nodes tolerate the same failures as three.","**Skip:** running consensus across high-latency links. Every write pays the round trip to a majority."],"readTime":"4 min read","wordCount":864},"related":[{"slug":"leader-election-explained-2026","title":"Leader Election Explained in 2026: How It Works","excerpt":"Leader election lets a cluster agree on a single coordinator without splitting into two. This guide explains how the mechanism works and why most systems delegate it to etcd or ZooKeeper.","category":"code","date":"August 6, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":316},{"slug":"consensus-algorithms-explained-2026","title":"Consensus Algorithms Explained in 2026: What They Guarantee","excerpt":"Consensus algorithms let a cluster agree on a value despite crashes and network delays. This guide explains what agreement, quorums, and fault tolerance actually guarantee in practice.","category":"code","date":"July 31, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":318},{"slug":"raft-vs-paxos-2026","title":"Raft vs Paxos in 2026: Comparing Consensus","excerpt":"Raft and Paxos solve the same consensus problem, but Raft was built to be understandable and correctly implementable. This guide compares both and explains why Raft dominates new systems.","category":"code","date":"August 8, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":320}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"model-warmup-strategies-2026","title":"Model Warmup: Why the First Request Is Always Slow","excerpt":"A freshly started inference replica serves its first requests far slower than its steady state. Warming it before traffic arrives is the difference between elastic and merely scalable.","category":"ai","date":"January 13, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":222},"older":{"slug":"react-agents-explained-2026","title":"ReAct Agents: Interleaving Reasoning and Tool Calls","excerpt":"Think, act, observe, repeat. The pattern behind most agent frameworks is simpler than the frameworks suggest, and understanding it explains most of how agents fail.","category":"ai","date":"January 13, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":220}}