In Search of an Understandable Consensus Algorithm

Ongaro, D., Ousterhout, & John. (2014). In Search of an Understandable Consensus Algorithm. 2014 USENIX Annual Technical Conference, 305-319.

Retired. This entry was not a citation. Our extractor stored an inline prose definition from the article as though it were a bibliographic record: the title names a concept rather than a published work, and the citation text names no work at all. The page is kept because links to it still resolve, but it is withdrawn from the reference list. This entry is kept so the citations that pointed at it still resolve, and so the correction is visible rather than silent.

Type

Conference paper

Intellectual base

Primary research

Year

2014

Pages

305-319

Link

no authoritative link yet

Cited from

computer_science, organizational_management, systems_cybernetics

Cited by

9 citations across 9 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes

• Authority Handoff
  • And in distributed systems it is leadership election, where a new leader is chosen, the prior leader's commitments are transferred by log replay, the new leader broadcasts authority to all replicas, and dependents redirect — the same structural pattern at a computational substrate.
• Fault Tolerance

  • This sourceIntroduces Raft, a consensus algorithm equivalent in guarantees to (multi-)Paxos but with a more understandable specification.

• Redundancy
  • The engineering methodology has influenced safety-critical computing across domains: nuclear-power control rooms, medical devices, air-traffic control systems, and autonomous-vehicle safety systems all employ variants of the triple-triple approach or similar multi-layer, diverse-redundancy designs

    This sourceRaft safety-critical computing domains.

Mechanisms

• Joint-Consensus Membership Change
  • The cluster went from three to five with no split-brain, no downtime, and no lost decision.

    This sourceShows a three-to-five Raft reconfiguration in which joint majorities prevent split brain while the cluster remains available and preserves committed state.

• Joint Consensus Reconfiguration
  • It is the disciplined answer to "how do we change the cluster while it is serving traffic," realized in systems that adopted the joint-consensus approach.

    This sourceIntroduces joint consensus for changing a live Raft cluster through overlapping old and new configurations.

• Quorum or Consensus Commit
  • It requires a live quorum to make progress, so a partition that leaves every side short of a quorum will (correctly) block: you cannot have commit-safety and availability during a partition at once.

    This sourceRequires a communicating majority for Raft to commit entries and explains that progress stops when no majority can communicate.

• Replicated Log Consensus Engine
  • Its strength is one durable command order, recoverable replica state, and efficient batching and pipelining — the replicated-log design at the heart of systems like etcd and other Raft-based stores.

    This sourceDefines Raft as a consensus algorithm for maintaining a coherent replicated command log with recoverable replicated state and efficient log replication.

• Term/Epoch Leader Election
  • At no point were there two primaries accepting writes in the same term, so no split-brain divergence could occur.

    This sourceGuarantees at most one Raft leader in a term and preserves log consistency so concurrent same-term primaries cannot create divergent committed histories.

• Write-Ahead Vote Log
  • The crash becomes invisible to the protocol's safety argument — exactly as that argument assumed.

    This sourceRequires Raft servers to persist the current term, vote, and log on stable storage before responding, preserving the state used by the safety argument across crashes.

Verification

Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.

Does it back the claim? Not recorded. Neither this nor any other of the 9 citations of this work carries a recorded support check.

Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 1 other way.

• https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro ×8

Registry ID ref:fca2e92801bb · see in the full table