Raft Made Consensus Understandable. It Did Not Make Consensus Scope-Aware.
by Nick Clark | Published March 28, 2026
The Raft consensus protocol made distributed consensus accessible by decomposing it into leader election, log replication, and safety guarantees. It has been implemented in etcd, Consul, CockroachDB, and dozens of other systems. But Raft governs a single replicated log through a single elected leader. All mutations, regardless of their scope, locality, or criticality, flow through the same leader and the same log. The structural gap is not in consensus reliability. It is in scope-awareness: whether different regions of the state space can govern themselves under different consensus requirements.
Raft's contribution to distributed systems is foundational. By making consensus understandable, it enabled an entire generation of reliable distributed infrastructure. The gap described here is not about correctness or understandability. It is about the architectural assumption that one consensus group governs one state space.
Single leader, single log
Raft elects a single leader that serializes all client requests into a log. The leader replicates log entries to followers and commits them once a quorum acknowledges receipt. This provides strong consistency and clear ordering.
But the single log means all mutations are globally ordered even when they affect independent state regions. Two mutations to unrelated parts of the state machine still compete for the leader's sequencing. The protocol cannot distinguish between mutations that need coordination and mutations that do not.
Multi-Raft, as implemented in systems like CockroachDB, runs multiple Raft groups on the same physical cluster. This helps with throughput but does not address governance. Each Raft group is still internally monolithic, and the boundaries between groups are determined by range splitting, not by governance requirements.
Consensus without governance differentiation
Raft applies identical consensus requirements to every entry in the log. There is no mechanism for certain state regions to require different quorum sizes, different trust validation, or different confirmation thresholds. A critical security policy mutation and a routine counter increment receive the same treatment.
The protocol is governance-uniform by design. This simplifies correctness proofs but limits applicability in environments where different state regions have fundamentally different governance needs.
What scope-governed consensus provides
Scope-governed consensus assigns each namespace segment its own anchor group with locally determined consensus requirements. Critical segments can require trust-weighted voting with higher thresholds. Ephemeral segments can use lightweight confirmation. The consensus requirements are a property of the scope, not a global constant.
In this model, mutations to one scope do not contend with mutations to another scope. Each scope's anchors validate and commit independently. Cross-scope coordination occurs only when mutations span scope boundaries, and it is governed by the policies of both participating scopes.
Raft's log replication and leader election mechanisms could serve as building blocks within each scope. But the scope boundaries, governance requirements, and structural adaptation would be governed by the adaptive index rather than being a property of a single consensus group.
The remaining gap
Raft made consensus understandable and reliable. The remaining gap is in scope-awareness: whether consensus can adapt its requirements to the governance needs of different state regions rather than applying uniform treatment to a single replicated log.
