When a majority is not enough

First, break something

The interactive lab on the home page starts with five reachable replicas. Take one offline and attempt a write. Take a second offline and try again. Both writes succeed in the model. Take a third offline, and the next write is refused.

This is the entire experiment: a fixed group of five members needs at least three reachable members to accept a write. The denominator stays five, even when members are offline. Otherwise, a minority could shrink its own idea of the group and declare itself a majority.

“Reachable” has a deliberately strong meaning here. Every online replica can communicate with every other online replica and with the client. There is no network delay, election, or partially connected topology. We are isolating the majority threshold, not implementing a distributed protocol.

Why three, rather than two?

Any two groups of three drawn from the same five members must overlap. For example, {R1, R2, R3} and {R3, R4, R5} share R3. Two groups of two need not overlap at all: {R1, R2} and {R4, R5} are disjoint.

That intersection is useful because it gives protocols a place where information about earlier decisions can survive into later decisions. But an overlap is a structural property, not a complete correctness proof. A shared replica must remember the right state, and the protocol must restrict what a new leader can propose.

The Raft paper makes these additional rules explicit. Its log-replication mechanism works together with election restrictions and a rule for committing entries from the leader’s current term. Counting replicas without these rules would miss essential parts of the algorithm. See sections 5.3 and 5.4 of Ongaro and Ousterhout.

What does “committed” mean here?

Each successful click appends one conceptual write to a single, authoritative sequence in your browser. Every reachable replica immediately advances to that sequence number. An offline replica retains the last sequence number it saw. A refused write changes neither the committed count nor any replica’s sequence.

There is no background retry. If a write is refused, restoring a replica does not later commit that attempt. You must explicitly attempt a new write. This makes the demonstration’s contract visible rather than hiding work in a queue.

In a real system, a timeout is more ambiguous. A server may have committed a request before the client lost its response. “I did not receive success” does not establish “nothing happened.” Request identifiers, deduplication, retry semantics, and a way to query an outcome matter at the API boundary.

Linearizability is a different, stronger statement than having several copies of data. Herlihy and Wing define the illusion that each operation takes effect at one instant between its invocation and response, while respecting the object’s sequential specification. A majority counter alone cannot establish that property. This lab does not model reads or concurrent operations, and it makes no such guarantee.

What the model leaves out

• Leadership and terms. There are no leaders, votes, terms, or election timeouts. A reachable majority is treated as immediately able to make progress. Real systems may need time and suitable communication conditions to elect a leader.
• Recovery and persistence. Taking a replica offline does not erase its state. Restoring it copies the model’s latest committed sequence immediately, even if no majority is reachable. This is an intentional shortcut using centralized browser state—not a claim that real recovery is instant or possible from any surviving disk.
• Partitions and clients. The controls remove replicas from a single connected group. They do not create competing partitions, asymmetric links, or clients that can reach only a minority.
• Concurrency and conflicting logs. One click completes synchronously before the next. There are no competing proposals, uncommitted suffixes, or divergent histories to reconcile.
• Membership changes. The set stays fixed at five. Reconfiguration needs its own safety mechanism; reducing a denominator is not one.
• Failure classes. There is no data loss, storage corruption, Byzantine behavior, snapshotting, or backpressure. Reset clears the entire experiment; it is not an operational recovery procedure.

These omissions are why the page says majority-availability model, not “Raft simulator.” The experiment explains a threshold. The cited papers explain the harder machinery around it.

A connection to CAP—not a proof

Imagine a real five-member system split into mutually disconnected groups of three and two. A correctly implemented majority-based protocol may continue processing on the majority side under suitable conditions. The minority side cannot independently acknowledge conflicting writes while preserving a single linearizable history.

This is related to the CAP trade-off, but the theorem is not “choose any two features” as a permanent product setting. Gilbert and Lynch discuss the impossibility of guaranteeing both atomic consistency and availability in the presence of network partitions. The model, the allowed executions, and the definitions matter.

CAP availability is not an uptime percentage. It requires requests to non-failing nodes to eventually complete with responses satisfying the service specification. Returning “unavailable” to a write is not satisfying that write’s specification. A reachable majority serving some clients does not mean the entire partitioned service meets CAP availability for every non-failing node.

Our offline-node switches cannot demonstrate the theorem: they never construct both sides of a partition or execute competing client histories. They only make one consequence of a majority write policy easy to inspect.

Questions for a real system

The interesting engineering work starts where the small model ends. Before translating this diagram into an availability promise, ask:

1. What exactly does a successful response guarantee? Memory replication, durable storage, a committed log entry, and external side effects are different boundaries.
2. Who can still reach whom? Count communicating members and reachable clients, not just green processes in a dashboard.
3. What survives restart? State which data must be durable and how a returning member is admitted and caught up.
4. How does the client resolve uncertainty? Specify safe retries, request identity, and the treatment of timeouts.
5. Which failures are correlated? Five replicas are not five independent failure domains if they depend on the same power, network, credentials, or deployment.

A clear model earns trust by showing its boundary. The goal is not to make a real system look as simple as five buttons. It is to know which part is simple—and which claims still need evidence.

Primary sources

1. Diego Ongaro and John Ousterhout, In Search of an Understandable Consensus Algorithm (extended version, 2014; PDF). Section 2 covers majority availability; sections 5.3–5.4 cover log replication and safety; section 6 covers membership changes.
2. Seth Gilbert and Nancy A. Lynch, Perspectives on the CAP Theorem (2012; PDF). Section 2 states the system model and consistency, availability, and partition assumptions; later sections discuss practical implications.
3. Maurice P. Herlihy and Jeannette M. Wing, Linearizability: A Correctness Condition for Concurrent Objects (1990; PDF). The original definition and a method for reasoning about concurrent objects.

Return to the experiment