Dissection · Ongaro & Ousterhout, 2014

Anatomy of Raft

In Search of an Understandable Consensus Algorithm, dissected: five servers laid out in 3D with their terms, votes, logs and state machines, Figures 7 and 8 rebuilt from real blocks, and a research desk that reruns the paper's leader-election measurements.

PaperOngaro & Ousterhout, USENIX ATC 2014 (extended version)

Modelfive servers, a seeded run, live

Reading39 min · 28 steps

Published2026-10-17

01Overview

Why elect a leader in order to keep a log?

Raft is a consensus algorithm for managing a replicated log [1]. Five servers hold copies of the same list of commands; Raft is the set of rules that keeps the copies identical while servers crash, restart and lose contact. Its authors say it produces a result equivalent to (multi-)Paxos, and that their primary goal was understandability.

What is on the table is that algorithm, built out of numbers. Each of the five rows is a server, laid out as the paper draws its logs in Figures 7 and 8. From left to right along a row: the server's state, its election timer, its log, the state machine the log feeds, and, on a leader, the two arrays it keeps about its followers. The glowing links are messages. Further up the table are the terms of this run, the paper's Figure 7 and Figure 8 as real blocks, the rules for compaction, every way of changing the cluster's membership, and the results of the research desk.

Nothing here is a drawing of data. The run is a seeded simulation of the rules in the paper's Figure 2, computed in this page, and test.mjs checks it against the paper's own figures, against the five properties of Figure 3 on 300 random executions with crashes, partitions, loss and duplication, and against the dissertation's closed-form results. The visual grammar, values as blocks of cells you can hover, follows Brendan Bycroft's LLM Visualization [2].

How to use this page

Scroll the article, or use ← →. Drag the stage to orbit, scroll on it to zoom; O shows the whole machine and R replays a step. Change the seed in the input and a different run is computed: other timeouts, other winners, other crashes. Dim amber is a follower, brighter a candidate, brightest a leader; a red flat block is a crashed server.

Go deeper: Raft · Consensus protocols · Replication

02Overview

One run on the table, thousands in the research desk

The paper describes an algorithm, not an execution, so there is nothing in it to transcribe except its figures; those get their own steps. The seed in the input chooses an execution: . Scrolling this step plays the whole of it, ending after a follower has been cut off and has come back.

The story of the run is the story of the article. A first leader is elected. Clients write three commands, which are replicated and committed. The leader appends a fourth entry to its own log and crashes before sending it. A second leader is elected, the first restarts, and its extra entry is deleted. A follower is then cut off and starts elections it cannot win, and when it returns its larger term unseats the leader. .

03Replicated state machines

The log is the thing being agreed on

A replicated state machine is a set of servers that compute the same state by running the same commands in the same order. In the paper's words, each server [1] stores a log, and since the state machines are deterministic, identical logs give identical state and identical outputs. Keeping the logs identical is the job of the consensus module, and it is all Raft does.

On the stage, each row holds that picture: the log block, one cell per entry with height and colour from the term in which the entry was created, feeds the state machine block to its right, three registers called $x$ , $y$ and $z$ . Entries are applied in log order, and each command is register ← value. After three commands have committed, all five state machine blocks are the same. .

Consensus here has the properties of a practical system [1]: it is safe, never returning an incorrect result, under all non-Byzantine conditions including delay, partition, loss, duplication and reordering; it is available as long as a majority of servers can talk to each other and to clients, so five servers, the usual number, tolerate two failures; and it does not depend on timing for the consistency of the logs.

Go deeper: Quorum · Write-ahead log · Linearizability

04Replicated state machines

What a server remembers, and what only a leader remembers

Figure 2 of the paper is the whole algorithm on one page, and its first box is the state. Three things are persistent, written to stable storage before the server answers any RPC: currentTerm, the latest term it has seen; votedFor, whom it voted for in that term; and the log. Two are volatile on every server: commitIndex, the highest entry known to be committed, and lastApplied, the highest entry fed to the state machine. Two arrays exist only on a leader and are rebuilt at every election: nextIndex, the next entry to send each follower, and matchIndex, the highest entry known to be on each follower.

Each of these is a block on the stage; the five cells of the first block, labelled R T V C A, are the role, the term, the vote, the commit index and the last applied index. Crash a server and every block of its row goes flat and red; the hover text says what survives. Its term, vote and log are still on disk; its commit index, applied index and state machine start again from zero when it restarts, as the run does later. That is the whole reason the first group is on disk: a server that forgot its vote could vote twice in a term, and a server that forgot its log could forget an entry it had promised to keep.

The paper's own figure fixes the language of everything that follows, so the engine is written against it rule by rule. Its formal counterpart, the TLA+ specification, names four message types: RequestVoteRequest, RequestVoteResponse, AppendEntriesRequest and AppendEntriesResponse [3]. The basic algorithm needs only two types of RPC, each with a reply.

Go deeper: Write-ahead log · Replication

05Leader election

Time is divided into terms, and a term is a logical clock

Raft cannot trust clocks, so it numbers its eras. [1] divides time into terms of arbitrary length; each begins with an election, and if the election is a split vote, the term ends with no leader. At most one leader can exist in a given term. The stage's terms block has a row for each term of this run and a column for each server: gold is the leader, magenta a server that timed out and stood, dark magenta one that only voted. .

The paper says that terms act as a logical clock and cites Lamport's paper on clocks and ordering [5]; the sibling dissection on this site, Anatomy of Lamport Clocks, builds that idea out of numbers. Terms are exchanged in every message, a server adopts any larger term it sees, and a request carrying a stale term is rejected. The rule that makes this a clock is in Figure 2's "All Servers" box: if an RPC carries a larger term, set currentTerm to it and convert to follower.

The run on the stage is numbered the same way. The cut-off follower later in the run is the case the rule exists for: .

Go deeper: Leader election · Clock and ordering · Clocks and ordering in practice

06Leader election

Every server is a follower until it hears nothing

Each server is in one of three states: leader, follower or candidate. In normal operation there is one leader and the rest are followers, which are passive: they answer requests and issue none. A candidate is a follower that has stopped hearing from a leader and is trying to become one. On the stage the first cell of each server's state block is its role, dim amber for a follower, brighter for a candidate and brightest for a leader; at the start of the run all five are followers and their election timers are filling.

The transitions are the paper's Figure 4. A follower that times out becomes a candidate; a candidate that wins becomes a leader; a candidate or leader that sees a larger term, or a candidate that hears from a legitimate leader, goes back to follower. A candidate returns to follower if the leader's term is at least as large as its own, and rejects an RPC with a smaller one.

Go deeper: Leader election · Leader election in practice

07Leader election

How does a server know the leader is gone?

It notices silence. Leaders send periodic heartbeats, AppendEntries RPCs that carry no log entries, to keep their authority; a follower that hears nothing for a period called the election timeout assumes there is no viable leader and begins an election. The strip of ten cells beside each server is that timer: it fills as time passes and resets whenever a valid AppendEntries arrives. .

A timer is the cheapest failure detector there is, and it is also the only place where Raft's liveness depends on time. The paper is careful about that line: safety must not depend on timing, while availability must. A wrong guess costs a pointless election and never a wrong answer.

The timeout is not a fixed length. It is drawn at random each time it resets, and the paper's example interval is 150–300 ms; the dissertation's way of saying it is that any individual server is expected to time out halfway through the range [4]. The author's own animation draws a timeout between one and two times a base of 100 ms, with message latency of 10 to 15 ms and a heartbeat at half the base timeout [6]. The reason is the next two steps: two servers whose timers end together are the one thing that can stop an election from finishing. Move the sliders in the figure below to see a single election as a race.

Go deeper: Jitter · Control heartbeat · Timeouts and deadlines

08Leader election

What does a candidate ask for, and who may say yes?

A follower that times out increments its term, transitions to candidate, votes for itself and sends RequestVote RPCs to every other server in parallel. On the stage the candidate's term cell goes up by one, its vote cell shows itself, and orange links go out; each reply comes back gold if the vote is granted and grey if it is not. .

A RequestVote carries four things: the candidate's term, its id, and the index and term of the last entry in its log. A voter grants the vote only if three conditions hold, in the order Figure 2 gives them:

the candidate's term is not smaller than the voter's own;
the voter has not already voted for someone else in this term (each server votes for at most one candidate in a given term, on a first-come-first-served basis);
the candidate's log is at least as up to date as the voter's, which is the restriction of §5.4 and has its own step later.

The first two are why at most one leader can be elected in a given term: a candidate needs votes from a majority of the servers in the full cluster, that is $⌊ n /2 ⌋ + 1$ of $n$ , no two majorities of the same set are disjoint, and nobody votes twice. A server that grants a vote also resets its election timer, so a server that has just voted does not immediately start an election of its own.

Go deeper: Quorum · Leader election

09Leader election

What does a new leader do first?

A candidate waits until it wins, until another server establishes itself as leader, or until a period of time goes by with no winner. This run takes the first: a majority of votes arrives, the role cell goes brightest, and the leader does three things at once. It sets every nextIndex to the index just after the last entry in its own log and every matchIndex to 0 (the two leader-only blocks fill in); it appends the no-op of §8; and it sends heartbeats to every server, which both stop new elections and begin the work of bringing the followers' logs into line with its own.

The heartbeat is an ordinary AppendEntries with nothing to carry, which is why the randomised timers add only a small amount of mechanism to the heartbeats already required for any consensus algorithm [1]. Each heartbeat that reaches a follower empties that follower's timer strip, which is what holds the cluster still. If the leader dies, the strips run out.

Go deeper: Leader election · Split brain

10Leader election

What if two servers stand at once?

If many followers become candidates at the same time, votes could be split so that no candidate obtains a majority, and without extra measures split votes could repeat indefinitely. This is not a flaw of Raft in particular. The dissertation traces it to the FLP result: no fault-tolerant consensus protocol can deterministically terminate in a purely asynchronous model, and this manifests itself in split votes in Raft [4][7]. Raft's answer is to make termination probable instead of certain.

The stage shows a split vote that is found for you. A cluster with timeouts drawn from 150 to 162 ms (far narrower than anyone should use, so that one is easy to find) is run from seeds starting at yours until a first term ends with no leader. . Each of those candidates has voted for itself, so every other server refuses it, and each needs a majority it cannot reach.

What breaks the tie is the same mechanism that caused it. Each candidate restarts its randomised timeout at the start of an election and waits for it to elapse before starting the next, so the next round draws fresh, different lengths and one server is likely to be first by more than a message delay. How likely is the subject of the research desk: it measures the split rate, finds where it takes over, and checks the dissertation's closed form against the simulation.

Go deeper: Split vote · Leader election

11Log replication

How does an entry get from the leader to the others?

The leader appends the command to its log as a new entry, then issues AppendEntries RPCs in parallel to each of the other servers to replicate the entry. On the stage a new cell grows at the end of the leader's log (its height is the leader's term), blue links go out, and each follower's log grows by the same cell a message-delay later. If a follower is slow or crashed, the leader retries indefinitely, even after it has responded to the client, until all followers eventually store all log entries.

This is Raft's strong leadership at work: log entries only flow from the leader to other servers, which is what lets the leader decide where each entry goes without asking anyone. An AppendEntries carries the leader's term and id, the entries to store (none for a heartbeat), the leader's commitIndex, and two numbers that matter more than the rest: prevLogIndex and prevLogTerm, the index and term of the entry that comes immediately before the new ones. They are the subject of the step after the next two.

The cost of an entry in the normal case is one message out and one back for each follower, and the leader needs only a majority of the replies: a new entry can be replicated with a single round of RPCs to a majority of the cluster. The cost table later measures it.

Go deeper: Replication · Synchronous versus asynchronous replication

12Log replication

When is an entry safe to apply?

An entry is committed once the leader that created it has replicated it on a majority of the servers, and that also commits all preceding entries in the leader's log, including entries created by previous leaders. The leader tracks the evidence in matchIndex, and Figure 2's last rule for leaders turns it into a decision:

If there exists an N such that N is greater than commitIndex, a majority of the matchIndex values are at least N, and the term of entry N equals currentTerm, set commitIndex to N. In symbols, with $c$ the leader's commit index,

\exists N > c : \land {i : matchIndex [i] \geq N} \geq ⌊ \frac{n}{2} ⌋ + 1 log [N] . term = currentTerm .

Read it as two conditions on the entry: enough servers hold it, and it was created in the term the leader is serving now. The second is not obvious and the step on Figure 8 is devoted to it. The leader tells the followers its commit index in every later AppendEntries, heartbeats included, so they set their own commitIndex to the smaller of the leader's and the index of the last new entry. On the stage a pale cell in a log marks an entry that server knows to be committed; as each server's lastApplied catches up, the three registers on its right fill in, in log order.

Go deeper: Quorum · Durability versus availability

13Log replication

How does a follower know its log matches?

It checks the entry before the new ones. When a leader sends entries, it includes the index and term of the entry that precedes them; if the follower has no entry at that index with that term, it refuses. The paper calls it an induction step: the empty logs satisfy the Log Matching Property, and the check preserves it whenever logs are extended. The property itself has two halves, the same index and term mean the same command (because a leader creates at most one entry with a given index in a given term) and the same index and term mean identical logs before it (because of the check).

The stage plays the case that needs it. . The new leader first sends from its own end: the check fails, nextIndex for that follower goes back by one, and it tries again. After a rejection, the leader decrements nextIndex and retries.

Go deeper: Replication · Write-ahead log

14Log replication

What can a new leader find, and what does it do about it?

The paper's Figure 7 shows six scenarios, (a) to (f), that could occur in follower logs when a new leader comes to power. They are reproduced on the stage as real blocks, the leader's ten-entry log on top and the six followers below, and run through the real AppendEntries code: a leader of term 8 with the log 1 1 1 4 4 5 5 6 6 6, and a new entry of its own term. The slider on the stage replays every message; the blocks beside the logs mark the leader's nextIndex for each follower walking left.

A follower may be missing entries (a, b), have extra uncommitted ones (c, d), or both (e, f). The leader's response is the same for all of them: it forces the followers' logs to duplicate its own, starting from the index just after the last one in its log, 11 in Figure 7. How many rejections each needs follows from the logs alone, and test.mjs recounts them by walking down both logs: (a) 1, (b) 6, (c) 0, (d) 0, (e) 5, (f) 7. Follower (f) is the extreme case: seven rejections, one per step back through entries of terms 3 and 2 that the leader never had.

Stepping back one entry at a time is the simplest rule and the paper offers a faster one: the follower reports the term of the conflicting entry and the first index it holds for that term, so the leader can skip a whole term at a time. With that, the same six followers need 1, 1, 0, 0, 2 and 2 rejections. The authors do not think it is needed: "in practice, we doubt this optimization is necessary, since failures happen infrequently and it is unlikely that there will be many inconsistent entries". The toggle in the figure runs both.

One consequence is a property that the paper states and the engine checks on every step: a leader never overwrites or deletes entries in its log; it only appends. All the overwriting is done to followers, by the leader, and never the other way round.

Go deeper: Replication · Write-ahead log

15Safety

Why can't just anyone be elected?

Because a new leader will overwrite followers' logs with its own, it must not be missing anything that was committed. [1] gets this by making the voters check. Some algorithms, such as Viewstamped Replication, let a leader be elected even if it does not initially contain all the committed entries and then ship the missing ones to it; Raft is simpler, at the price of a rule: the voter denies its vote if its own log is more up-to-date than that of the candidate.

"More up to date" has a precise meaning: compare the last entries; the later term wins, and if the terms are equal the longer log wins. With $(t_{c}, i_{c})$ the term and index of the candidate's last entry and $(t_{v}, i_{v})$ the voter's, the vote may be granted only if

(t_{c}, i_{c}) \geq (t_{v}, i_{v}) in lexicographic order.

Why this is enough: a committed entry is on a majority, and a candidate needs a majority, so at least one voter holds every committed entry; if that voter would grant the vote, the candidate's log is at least as up to date as the voter's, and the Log Matching Property then puts the entry in the candidate's log too. That is the argument of §5.4.3 in outline.

The stage runs a small election to show the rule working. Five servers hold logs of length 4, 4, 3, 2 and 1. . The rule did not stop an election; it stopped the election of a server that could have erased entries. The checker on the stage's other run confirms that nothing was lost: .

Go deeper: Leader election · Quorum

16Safety

Why does the leader not count replicas of an old entry?

It looks safe to. If an entry from an earlier term is on a majority of servers, the natural conclusion is that it is committed. Figure 8 of the paper is the counterexample. In panel (a) S1 leads term 2 and replicates entry 2 to S2 only. In (b) S1 crashes and S5, elected for term 3 with votes from S3, S4 and itself, accepts a different entry at index 2. In (c) S5 crashes, S1 restarts, is elected for term 4, and continues replicating: entry 2, from term 2, is now on S1, S2 and S3, a majority of five. If it counted that as committed and then crashed, S5 could be elected again, with votes from S2, S3 and S4, since its last term is later than theirs, and overwrites it: panel (d) [1].

The remedy is a rule about which entries a leader may commit by counting. Raft never commits log entries from previous terms by counting replicas; a leader counts only for entries of its current term, and once one is committed, all preceding entries are committed indirectly. In (e), S1 replicates an entry from term 4 on a majority first, and then it is committed and S5 cannot win an election. This is the second condition in the commit rule, $log [N] . term = currentTerm$ .

Panels (a) to (c) on the stage are the paper's; (d) and (e) are computed: the engine starts from panel (c) and runs the crash and the election. With Raft's rule S1's commit index stays 0 and S5 overwrites entry 2, which is harmless because it was never committed. Flip the rule in the figure below and the same run commits entry 2, applies it, and then loses it, which the checker reports as a violation of Leader Completeness and of State Machine Safety. The authors note the rule is more conservative than necessary, for simplicity, and that the cost is that log entries keep their original term numbers when a later leader replicates them, which makes them easier to reason about.

Go deeper: Quorum · Replication

17Safety

What exactly is guaranteed, and how is it checked here?

Figure 3 lists five properties that Raft guarantees "at all times". The engine evaluates each as the simulation runs:

Election Safety: at most one leader can be elected in a given term. Checked at every election against all earlier leaders of that term.
Leader Append-Only: a leader never overwrites or deletes entries in its log. Checked against the leader's log at each step.
Log Matching: if two logs contain an entry with the same index and term, the logs are identical in all entries up through the given index. Checked over every pair of servers.
Leader Completeness: a committed entry is present in the logs of the leaders of all higher terms. Checked against every entry ever committed, at every election.
State Machine Safety: no server applies a different entry at an index than another has. Checked on every apply.

The paper's argument for the last two is §5.4.3, a proof by contradiction. Suppose the leader of term $T$ commits an entry and some later leader does not hold it, and take the smallest such term $U$ . The entry was on a majority and $U$ 's leader had a majority of votes, so at least one server, "the voter", both accepted the entry and voted for the later leader. The voter had the entry when it voted, since leaders never delete entries and followers delete only on conflict; the voter granted its vote, so $U$ 's leader was at least as up to date; and either case, equal last terms with a longer log, or a later last term created by a leader that had the entry, puts the entry in $U$ 's log. The contradiction finishes the proof.

The stage shows the end state of the live run: identical logs up to the pale cells on every server, and state machines that agree wherever they have applied the same entries. . Try to break the properties in the figure below. Raft as written survives every random execution; removing the election restriction breaks Leader Completeness in a large share of them.

Go deeper: Split brain · Linearizability

18Practical matters

What must be true of the clocks for any of this to work?

The paper is plain about what safety needs of time (nothing) and liveness needs (a lot). Raft will elect and keep a steady leader as long as

broadcastTime ≪ electionTimeout ≪ MTBF .

Here broadcastTime is the average time it takes a server to send RPCs in parallel to every server and receive the responses, and MTBF is the mean time between failures of one server. The first inequality is the one a reader can break: the broadcast time should be an order of magnitude less than the election timeout so that heartbeats arrive before timers end. The authors' numbers: a broadcast time of 0.5 ms to 20 ms, so an election timeout somewhere between 10 ms and 500 ms, against server MTBFs of several months or more, and an election timeout a few orders of magnitude below the MTBF so that the cluster makes steady progress. When the leader does crash, the system is unavailable for roughly the election timeout.

The stage shows the first inequality at work: the leader's heartbeats, every half of the minimum timeout, empty each follower's timer strip before it fills. Nothing in the paper says where the rule stops being enough. That is the third experiment of the research desk, which draws latencies from a heavy-tailed distribution and counts the followers that time out while the leader is perfectly healthy.

Go deeper: Tail latency · Percentile latency · Timeout budget

19Practical matters

Why can't a cluster just switch to its new configuration?

Because servers cannot switch at the same instant. Any approach where servers switch directly from the old configuration to the new configuration is unsafe: the cluster can split into two independent majorities during the transition (the paper's Figure 10). Going from three servers to five, S1 and S2 can still be using the old configuration while S3 to S5 already use the new one; S1 needs two votes of the three, S3 needs three of the five, and the two groups share no server.

The stage enumerates every combination. Each row of the first block is a case: which configuration each of five servers is using, old (blue) or new (amber). The flag beside it is set when two candidates can win the same term with voter sets that do not overlap. . The second block is the paper's answer, a transitional configuration called joint consensus, under which agreement requires separate majorities from both the old and new configurations; its 84 cases include every mix of old, joint and new servers that can exist, and none is flagged. The enumeration leaves the election restriction doing one job: once the joint entry is committed, servers that lack it cannot win.

The rest of §6 is three practical issues: new servers first join as non-voting members so that catching up cannot stall commits; a leader not in the new configuration steps down once the new entry is committed; and removed servers can disrupt the cluster, which the paper cures by having servers ignore a RequestVote within the minimum election timeout of hearing from a leader. A server also uses the latest configuration in its log, committed or not.

Go deeper: Joint consensus · Witness replica

20Practical matters

What happens when the log grows without bound?

It has to be cut. Snapshotting is the simplest approach to compaction: write the whole state machine to disk and discard the log up to that point. Each server takes snapshots independently, covering just the committed entries in its log, and it records a last included index and a last included term so the consistency check still works for the entry that follows. Figure 12's rules for the receiver are on the stage as three cases.

A follower that has fallen behind a leader that has already discarded the entries it needs is sent a snapshot: the leader uses a new RPC called InstallSnapshot. What the follower does with its own log depends on whether the snapshot's last entry is in it: if so, the entries after it are kept (entries covered by the snapshot are deleted but entries following it are still valid); if not, the whole log goes. The three rows are the prefix case, a case where the last included term does not match, and a snapshot that reaches beyond the log; the blocks beside them show what is left. test.mjs checks them against the rule as the paper writes it.

Go deeper: Snapshotting · Log compaction

21Practical matters

What does a client see when a leader dies mid-command?

It sees a timeout and tries again. A client that does not know the leader contacts a randomly chosen server, which refuses and names the most recent leader it has heard of. The stage replays the worst moment: . The entry was never sent, so no follower has it, and it can never be committed; the client's request will time out and be retried elsewhere.

Retries inside the cluster are harmless for a similar reason: when a follower crashes, Raft retries indefinitely, and if the server restarts the RPC completes, and Raft RPCs are idempotent, so an AppendEntries that arrives twice changes nothing the second time. A client's retry can be a duplicate, if the leader crashed after committing but before replying. The remedy is unique serial numbers on every command: the state machine remembers the last serial number per client and answers a repeat without executing it. test.mjs sends the same serial twice and checks that the register changes once. The log does hold both entries; deduplication happens when the entries are applied. Reads have two precautions of their own, so that a leader that has been deposed does not answer from stale state: a leader commits a no-op entry at the start of its term to learn its commit index (the dissertation's account is the clearest) [4], and it exchanges heartbeats with a majority before answering a read-only request. Leases would avoid that round trip, but would rely on timing for safety.

Go deeper: Idempotency · Exactly-once semantics · Lease read · Fencing token

22Evaluation

Is it easier to understand than Paxos?

That is the question the paper was written to answer, and §9.1 measures it. A user study with 43 students at two universities had each student watch a lecture on Raft and one on Paxos, in both orders, and take a quiz after each. The mean Raft score was 25.7 and the mean Paxos score 20.8, out of 60, and 33 participants scored higher for Raft. A paired t-test puts the true difference at least 2.5 points at 95% confidence. The two bars on the stage are those means.

The authors list the biases they could find. Fifteen of the 43 had prior Paxos experience, and the Paxos video was 14% longer, both in Paxos's favour. They also report that 33 of 41 participants said Raft would be easier to implement and to explain, which they warn is self-reported and may reflect knowing their hypothesis. The paper does not say why 41 answered a survey that 43 took the quiz for. The argument for Paxos's difficulty is the paper's own: "Paxos is exceptionally difficult to understand" [1], and the Raft authors report that understanding it and designing their own alternative was a process that took almost a year.

What this page can add is not a measurement of understanding, which it cannot make. The structure that the authors credit, decomposition into leader election, log replication and safety, is visible in the layout: election and replication are different blocks of the same row, and safety is a property of how they are joined.

Go deeper: Consensus protocols · Byzantine fault

23Evaluation

How many messages does one command take?

In the normal case, with an established leader, the answer is the smallest it can be: a single round trip from the leader to half the cluster [1]. For $n$ servers the leader sends $n - 1$ AppendEntries and receives $n - 1$ replies, $2 (n - 1)$ messages in all, and commits when a majority, itself included, has the entry. The engine measures it:

Raft's strong leadership has a price that the authors name. They compare it with leaderless Egalitarian Paxos [10], which can commit in one round of communication when concurrent commands commute, and has lower latency than Raft in wide-area settings; Raft concentrates the work in the leader, which makes it simpler and rules out that optimisation. They also count message types: Viewstamped Replication and ZooKeeper each define 10, Raft 4 [11][12]. The implementation in the paper is roughly 2000 lines of C++ [1].

Go deeper: Replication · Quorum

24Research desk

E1 · Does the simulation reproduce Figure 16?

Claim

The paper's §9.3 reports how long a five-server cluster is without a leader after the leader is crashed, as a function of the election timeout range. In the absence of randomness, leader election consistently took longer than 10 seconds; 5 ms of randomness gave a median of 287 ms; 50 ms gave a worst case of 513 ms over 1000 trials; and timeouts of 12–24 ms gave 35 ms on average, longest 152 ms.

Hypotheses

H1a to H1f in research/README.md: the four numbers above, the shape (no worse with more randomness), and that 150–300 ms never takes a second. Each has a numeric verdict rule, fixed before the first run.

Design

The paper repeatedly crashed the leader of a five-server cluster; here, the paper's worst case: a synchronised heartbeat broadcast just before the crash, the crash uniformly within the heartbeat interval, half the minimum timeout, survivors with different log lengths, so that some cannot win. Network 2–6 ms and disk 4–10 ms, so that a broadcast averages the paper's roughly 15 ms. 1000 trials per arm, three independent seed sets.

The dissertation reports the small-timeout case again for its own implementation: a leader elected in an average of 35 ms on a LAN with aggressive timeouts, though it suggests a more conservative range in practice [4].

Lab note: a mistake that changed the result

The first run of E1 was far from the paper: with 5 ms of randomness the median was 764 ms against 287 ms, and the slowest of 1,000 trials with 50 ms was about 2 s against 513 ms. The cause was in the engine, not the paper: it reset a server's election timer on any RPC with a higher term, where Figure 2 resets it only on a valid AppendEntries or a granted vote. In the paper's worst case the two servers that cannot win kept calling elections and, through the extra reset, kept postponing the two that can. The engine was corrected, test.mjs now pins the rule, and every experiment was re-run from scratch with the hypotheses and verdict rules untouched. The first-run numbers are in research/LAB-NOTES.md. H1d asked the wrong question (the paper's claim is about the worst case, not the median), which is why its verdict is negative; it is reported as written.

Go deeper: Multi-seed reporting and run-to-run variance · Monte Carlo methods

25Research desk

E2 · Where do split votes take over, and is the formula right?

The dissertation derives the probability that a first term ends in a split vote, with $s$ of $n$ servers up and a fixed one-way latency $l$ , measured as a fraction of the timeout range $R$ [4]. A split needs $c$ servers to time out within $l$ of the first, where

c = s - ⌊ \frac{n}{2} ⌋ + 1, Pr (split) = k = c - 1 \sum s (k s) l^{k} (1 - l)^{s - k} .

From it the dissertation concludes that each election term is essentially memoryless, so that the number of terms follows a geometric distribution with mean $1/ (1 - p)$ for a split rate $p$ ; that the expected time to a leader, in units of the timeout range with timeouts on $[1, 2]$ , is

E = \frac{1}{1 - p} (1 + \frac{1}{s + 1} + l) + l;

that the curves become linear beyond a knee at about 3–8 times the network latency; and that a range of 10–20 times the latency keeps split rates under 40%.

Claim

The formula for the split rate, the geometric terms, the expected time, the knee and the 40% bound, as stated above, are untested outside the dissertation's own small simulation.

Hypotheses

H2a: the formula matches the simulated split rate in every cell. H2b: terms are geometric to within 5%. H2c: the election time is minimised at

R / l

between 3.3 and 6.7 for

s

= 5, 4, 3. H2d: the formula's election time is within 15%. H2e: under 40% at

R / l

= 10. Verdict rules fixed before the run.

Design

Five servers,

s

in {5, 4, 3} up, timeouts uniform on

[R, 2 R]

, fixed latency

l = ρR

for seven values of

ρ

, three seed sets of 20,000 elections per cell (21 cells). The same grid with latency uniform on

[0.5 l, 1.5 l]

is exploratory.

The dissertation's headline for the normal case is that when no split vote occurs, elections complete about one third of the way into the timeout range, and it advises a conservative setting, specifically a range ten times the one-way latency. Its simulated wide-area result is that elections typically complete in half a second, and 99.9% in 3 seconds, even with two of five servers failed. The first quantity is checkable by hand: with four servers up, the first of four uniform timeouts is expected one fifth of the way through the range, that is $E [M_{s}] = 1/ (s + 1)$ , and test.mjs confirms the formula against the numbers the dissertation quotes: 0.06%, 5.2% and 18.1% for a five-server cluster with one failure at latencies of 1, 10 and 20 ms in a 100 ms range, about half with two failures at $l = 0.2$ , and nearly 70% for nine servers with four down.

Go deeper: Split vote · Seeds and the limits of determinism

26Research desk

E3 · Where does the timing requirement break?

Claim

broadcastTime ≪ electionTimeout ≪ MTBF, with the broadcast time an order of magnitude below the election timeout. Lowering the timeouts beyond this point violates Raft's timing requirement: leaders have difficulty broadcasting heartbeats before other servers start new elections, and 150–300 ms is recommended. The paper does not measure where the rule stops being enough, and the dissertation advises the other direction for testing: a very low election timeout and a very high heartbeat interval produce more leader changes.

Hypotheses

H3a: with bounded latency (uniform 2–6 ms) there are no spurious elections at any timeout of 20 ms or more. H3b: with heavy-tailed latency of the same mean, a timeout of 150 ms, ten times the mean broadcast, still gives at least one per hour. H3c: the heavy-tailed rate does not rise with the timeout.

Design

Five healthy servers, a stable leader, no failures, loss or partitions. Followers' timeouts on

[t, 2 t]

with

t

in {15, 20, 30, 45, 75, 150, 300} ms, heartbeat

t /2

, 60 simulated minutes per arm and seed set, three sets. Latency uniform 2–6 ms or log-normal with mean 4 ms and

σ = 1.0

(99th percentile near ten times the mean);

σ = 0.5

and

1.5

are exploratory.

Go deeper: Tail latency · Jitter · Clock drift

27Research desk

What this leaves open

Which candidates' disk writes? The exploratory arm of E1 shows that whether a candidate writes its vote before sending RequestVote moves the answer by an order of magnitude. Measuring that on a real implementation, and with the overlap the dissertation mentions, would decide between the readings.
Pre-Vote under the same attack. The dissertation says Pre-Vote has a candidate increment its term only after a majority says it would vote for it and that it does not appear to significantly harm election performance [4]. Repeating E1 and E3 with Pre-Vote, and counting the leaders it prevents from stepping down when a cut-off server returns (the last act of the live run), is a direct extension.
Skewed networks. The dissertation lists asymmetric networks, severe packet loss and clock drift as open. Both E2 and E3 have symmetric latency and no loss.
Memory in the terms. H2b's gap at the narrowest ranges is where the dissertation says "essentially memoryless" and the simulation disagrees a little. Deriving the correction from the vote-triggered timer resets would say whether it can be ignored at every cluster size.
The 5.2 rule, in production. The engine's first run reset timers on every higher-term RPC and nearly doubled the median downtime in the paper's worst case. Whether real implementations drifted the same way is an empirical question about code, and the cheapest test is the one in test.mjs.

28Research desk

What was read, what was not, and how to check it

The primary source, the extended version of [1], was read in full: text, tables, every figure caption, and the drawings of Figures 7 and 8 from the rendered pages. The sandbox could not reach raft.github.io, arxiv.org or usenix.org, so the PDF was read from the public raft/raft.github.io repository at a pinned commit, and quotes were checked against the text extracted from it. Where a sentence runs across a page break in the extraction, the ledger quotes only what is contiguous and says so. The dissertation [4], the TLA+ specification [3] and the RaftScope source [6] were read as source files at pinned commits.

Not read in this run, and cited only for what the Raft paper or the dissertation says about them: the Paxos papers [13][14], Viewstamped Replication [11], the FLP paper [7], Howard's analysis [8], EPaxos [10], the log-structured merge tree [9], linearizability [15], the SMART migration paper [16] and ZooKeeper [12]. Later literature on Raft, for example work comparing Raft with Multi-Paxos or reporting liveness problems in practice, is not cited because it could not be fetched. Raft's use of a logical clock owes its idea to [5].

Everything is reproducible from engine.js (the model), test.mjs (the truth checks), research/README.md (the pre-registration, written before the first run), research/run.mjs, research/summarise.mjs (which applies the verdict rules and writes the result paragraphs on this page), and research/LAB-NOTES.md. The visual grammar follows Bycroft's tensor visualisation [2].

Go deeper: Multi-seed reporting and run-to-run variance · Seeds and the limits of determinism · Distributed systems · Partition tolerance · Raft

References

Ongaro, D. and Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm (Extended Version). Stanford University technical report, 20 May 2014; the extended version of the USENIX ATC '14 paper The subject of this page. Read in full (every section, table and figure caption, and the drawings of Figures 7 and 8 from the rendered pages) from raft.pdf as committed in the raft/raft.github.io repository at commit de64ee6; raft.github.io, arxiv.org and usenix.org could not be reached from the sandbox. Figures 7 and 8 were read from the rendered pages. Every quote in the fact ledger was checked against the extracted text of that file.
Bycroft, B. (2023). LLM Visualization. bbycroft.net The visual grammar of values as blocks of cells that this page follows.
Ongaro, D. (2014). The Raft TLA+ specification (raft.tla). github.com/ongardie/raft.tla, commit 6ecbdbc (CC BY 4.0) The formal specification the paper cites for the five properties. Read for its message types and variables; the page's engine is not a transcription of it.
Ongaro, D. (2014). Consensus: Bridging Theory and Practice. PhD dissertation, Stanford University Read as LaTeX source at commit 0c10ea1 (CC BY): the chapters on leader election, cluster membership, client interaction and correctness. It holds the closed-form split-vote analysis, the Pre-Vote extension and the later single-server membership change that this page tests and cites.
Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM 21(7), 558–565 Reference [14] of the Raft paper, cited there for the logical clock that terms resemble. Not re-read for this page; the sibling dissection on this site covers it.
Ongaro, D. (2014). RaftScope. github.com/ongardie/raftscope, commit 5b0c10a The author's own animation of Raft. Its source was read for its constants (a base election timeout of 100,000 microseconds drawn between one and two bases, message latency 10 to 15 ms, heartbeat at half the base timeout).
Fischer, M. J., Lynch, N. A. and Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. Journal of the ACM 32(2), 374–382 The FLP result, cited by the dissertation for why election time cannot be bounded. Not read in this run; cited only for the sentence the dissertation attaches to it.
Howard, H. (2014). ARC: analysis of Raft consensus. University of Cambridge Computer Laboratory technical report UCAM-CL-TR-857 Cited by the dissertation for separating candidates' timeouts from followers'. Not read in this run; cited only for the sentence the dissertation attaches to it.
O'Neil, P., Cheng, E., Gawlick, D. and O'Neil, E. (1996). The log-structured merge-tree (LSM-tree). Acta Informatica 33(4), 351–385 Reference [30] of the Raft paper, cited there as an incremental alternative to snapshotting. Not read in this run.
Moraru, I., Andersen, D. G. and Kaminsky, M. (2013). There is more consensus in egalitarian parliaments. SOSP '13 Reference [27] of the Raft paper (EPaxos), cited for the trade-off the paper states in §10. Not read in this run.
Liskov, B. and Cowling, J. (2012). Viewstamped replication revisited. MIT technical report MIT-CSAIL-TR-2012-021 Reference [22] of the Raft paper: the algorithm Raft is most similar to. Cited only for what the Raft paper says about it. Not read in this run.
Hunt, P., Konar, M., Junqueira, F. P. and Reed, B. (2010). ZooKeeper: wait-free coordination for Internet-scale systems. USENIX ATC '10, 145–158 Reference [11] of the Raft paper, named there as a replicated state machine and as a system that, like Raft, is leader based. Not read in this run.
Lamport, L. (1998). The part-time parliament. ACM Transactions on Computer Systems 16(2), 133–169 Reference [15] of the Raft paper: the Paxos paper. Cited only for what the Raft paper says about it. Not read in this run.
Lamport, L. (2001). Paxos made simple. ACM SIGACT News 32(4), 18–25 Reference [16] of the Raft paper. Cited only for what the Raft paper says about it. Not read in this run.
Herlihy, M. P. and Wing, J. M. (1990). Linearizability: a correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems 12(3), 463–492 Reference [10] of the Raft paper, for the semantics Raft's clients get. Not read in this run.
Lorch, J. R., Adya, A., Bolosky, W. J., Chaiken, R., Douceur, J. R. and Howell, J. (2006). The SMART way to migrate replicated stateful services. EuroSys '06, 103–115 Reference [24] of the Raft paper: a membership-change method it compares with. Cited only for what the Raft paper says about it. Not read in this run.

Fact ledger

Every number from the literature on this page, with the sentence it comes from. Hover any underlined number in the text to see its entry.

Value	What	Source
a consensus algorithm for managing a replicated log	Raft	[1] Abstract Raft is a consensus algorithm for managing a replicated log.
equivalent in result, as efficient, different in structure	Raft against Paxos	[1] Abstract It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos
understandability	the primary goal	[1] §1 our primary goal was understandability
five	a typical cluster	[1] §5.1 A Raft cluster contains several servers; five is a typical number, which allows the system to tolerate two failures.
four	the TLA+ specification's message types	[3] raft.tla CONSTANTS RequestVoteRequest, RequestVoteResponse, AppendEntriesRequest, AppendEntriesResponse
two	RPC types in the basic algorithm	[1] §5.1 the basic consensus algorithm requires only two types of RPCs
sends initial empty AppendEntries	Figure 2, a new leader	[1] Figure 2 Upon election: send initial empty AppendEntries RPCs (heartbeat) to each server; repeat during idle periods to prevent election timeouts (§5.2)
commits a blank no-op entry	a new leader	[1] §8 Raft handles this by having each leader commit a blank no-op entry into the log at the start of its term.
with no leader	a split vote ends a term	[1] §5.1 In this case the term will end with no leader
a logical clock	terms	[1] §5.1 Terms act as a logical clock [14] in Raft, and they allow servers to detect obsolete information such as stale leaders.
rejected	a stale request	[1] §5.1 If a server receives a request with a stale term number, it rejects the request.
a larger term always converts to follower	Figure 2, all servers	[1] Figure 2 If RPC request or response contains term T > currentTerm: set currentTerm = T, convert to follower (§5.1)
leader, follower or candidate	server states	[1] §5.1 At any given time each server is in one of three states: leader, follower, or candidate.
returns to follower state if the term is at least its own	a candidate that hears from a leader	[1] §5.2 If the leader’s term (included in its RPC) is at least as large as the candidate’s current term, then the candidate recognizes the leader as legitimate and returns to follower state.
valid RPCs from a leader or candidate	section 5.2, followers	[1] §5.2 RPCs from a leader or candidate. Leaders send periodic heartbeats
convert on a timeout without AppendEntries or a granted vote	Figure 2, followers	[1] Figure 2 If election timeout elapses without receiving AppendEntries RPC from current leader or granting vote to candidate: convert to candidate
does not grant its vote or reset its timer	a voter with a more up-to-date log	[4] §What happens when logs differ? a voter does not grant its vote or reset its election timer if the voter's log is more up-to-date than the candidate's.
AppendEntries RPCs that carry no log entries	heartbeats	[1] §5.2 Leaders send periodic heartbeats (AppendEntries RPCs that carry no log entries) to all followers in order to maintain their authority.
a period of time with no communication	election timeout	[1] §5.2 If a follower receives no communication over a period of time called the election timeout, then it assumes there is no viable leader and begins an election to choose a new leader.
safety does not depend on timing	the timing requirement	[1] §5.6 One of our requirements for Raft is that safety must not depend on timing: the system must not produce incorrect results just because some event happens more quickly or slowly than expected.
chosen randomly from a fixed interval (e.g., 150–300ms)	election timeouts	[1] §5.2 To prevent split votes in the first place, election timeouts are chosen randomly from a fixed interval (e.g., 150–300ms).
halfway through the range	a single server's timeout	[4] §How fast will Raft elect a leader with no split votes? Intuitively, any individual server is expected to time out halfway through the election timeout range
a base of 100000 microseconds, drawn between one and two bases	RaftScope election timeout	[6] raft.js return now + (Math.random() + 1) * ELECTION_TIMEOUT;
100000 microseconds	RaftScope base timeout	[6] raft.js var ELECTION_TIMEOUT = 100000;
10000 to 15000 microseconds	RaftScope message latency	[6] raft.js var MIN_RPC_LATENCY = 10000; var MAX_RPC_LATENCY = 15000;
half the base election timeout	RaftScope heartbeat	[6] raft.js server.heartbeatDue[peer] = model.time + ELECTION_TIMEOUT / 2;
increment the term, vote for itself, ask the others	beginning an election	[1] §5.2 To begin an election, a follower increments its current term and transitions to candidate state. It then votes for itself and issues RequestVote RPCs in parallel to each of the other servers in the cluster.
at most one, first come first served	votes per term	[1] §5.2 Each server will vote for at most one candidate in a given term, on a first-come-first-served basis
at most one leader per term	Election Safety	[1] Figure 3 Election Safety: at most one leader can be elected in a given term.
a majority of the full cluster	winning	[1] §5.2 A candidate wins an election if it receives votes from a majority of the servers in the full cluster for the same term.
three	outcomes of an election	[1] §5.2 A candidate continues in this state until one of three things happens: (a) it wins the election, (b) another server establishes itself as leader, or (c) a period of time goes by with no winner.
a small amount of mechanism on top of heartbeats	randomised timers	[1] §1 This adds only a small amount of mechanism to the heartbeats already required for any consensus algorithm, while resolving conflicts simply and rapidly.
a ranking system	the first design	[1] §5.2 Initially we planned to use a ranking system: each candidate was assigned a unique rank, which was used to select between competing candidates.
new corner cases appeared	why ranking was dropped	[1] §5.2 We made adjustments to the algorithm several times, but after each adjustment new corner cases appeared.
many candidates at once	split votes	[1] §5.2 if many followers become candidates at the same time, votes could be split so that no candidate obtains a majority.
split votes could repeat indefinitely	without randomisation	[1] §5.2 However, without extra measures split votes could repeat indefinitely.
no deterministic termination in an asynchronous model	the dissertation on termination	[4] ch. Leader election evaluation According to the FLP impossibility result, no fault-tolerant consensus protocol can deterministically terminate in a purely asynchronous model.
the manifestation of FLP	split votes	[4] ch. Leader election evaluation This manifests itself in split votes in Raft, which can potentially impede progress repeatedly during leader election.
restarts its randomized timeout	a candidate after a split vote	[1] §5.2 Each candidate restarts its randomized election timeout at the start of an election, and it waits for that timeout to elapse before starting the next election; this reduces the likelihood of another split vote in the new election.
a smaller range for candidates	separate candidate timeouts	[4] §How fast will Raft elect a leader when split votes are possible? The optimization separates followers' timeouts from candidates' timeouts, where candidates select smaller timeouts from a distribution with a smaller range.
appended, then replicated	a client request	[1] §5.3 The leader appends the command to its log as a new entry, then issues AppendEntries RPCs in parallel to each of the other servers to replicate the entry.
AppendEntries retried indefinitely	a slow or crashed follower	[1] §5.3 the leader retries AppendEntries RPCs indefinitely (even after it has responded to the client) until all followers eventually store all log entries.
log entries flow only from the leader	strong leadership	[1] §1 log entries only flow from the leader to other servers.
a single round of RPCs to a majority	a normal commit	[1] §5.3 in the normal case a new entry can be replicated with a single round of RPCs to a majority of the cluster
replicated on a majority	committed	[1] §5.3 A log entry is committed once the leader that created the entry has replicated it on a majority of the servers (e.g., entry 7 in Figure 6).
also commits all before it	committing an entry	[1] §5.3 This also commits all preceding entries in the leader’s log, including entries created by previous leaders.
a majority, and the entry from the current term	the leader's commit rule	[1] Figure 2 If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N (§5.3, §5.4).
commitIndex = min(leaderCommit, index of last new entry)	receiver step 5	[1] Figure 2 If leaderCommit > commitIndex, set commitIndex = min(leaderCommit, index of last new entry)
an induction step	the consistency check	[1] §5.3 The consistency check acts as an induction step: the initial empty state of the logs satisfies the Log Matching Property, and the consistency check preserves the Log Matching Property whenever logs are extended.
same index and term, same command	Log Matching, part one	[1] §5.3 If two entries in different logs have the same index and term, then they store the same command.
follows from one entry per index per term	the first Log Matching property	[1] §5.3 The first property follows from the fact that a leader creates at most one entry with a given log index in a given term, and log entries never change their position in the log.
same index and term, same history	Log Matching, part two	[1] §5.3 If two entries in different logs have the same index and term, then the logs are identical in all preceding entries.
the leader decrements nextIndex and retries	a rejected AppendEntries	[1] §5.3 After a rejection, the leader decrements nextIndex and retries the AppendEntries RPC.
the follower's log is consistent with the leader's	after AppendEntries succeeds	[1] §5.3 Once AppendEntries succeeds, the follower’s log is consistent with the leader’s, and it will remain that way for the rest of the term.
delete an existing entry that conflicts with a new one	receiver step 3	[1] Figure 2 If an existing entry conflicts with a new one (same index but different terms), delete the existing entry and all that follow it (§5.3)
six possible follower logs	Figure 7	[1] Figure 7 When the leader at the top comes to power, it is possible that any of scenarios (a–f) could occur in follower logs.
followers duplicate the leader’s log	the leader forces the logs	[1] §5.3 In Raft, the leader handles inconsistencies by forcing the followers’ logs to duplicate its own.
just after the leader’s last entry (11 in Figure 7)	nextIndex at election	[1] §5.3 it initializes all nextIndex values to the index just after the last one in its log (11 in Figure 7).
optional; the authors doubt it is needed	skipping a term at a time	[1] §5.3 In practice, we doubt this optimization is necessary, since failures happen infrequently and it is unlikely that there will be many inconsistent entries.
a leader only appends	Leader Append-Only	[1] Figure 3 Leader Append-Only: a leader never overwrites or deletes entries in its log; it only appends new entries.
a leader can be elected without all committed entries	Viewstamped Replication	[1] §5.4.1 In some consensus algorithms, such as Viewstamped Replication [22], a leader can be elected even if it doesn’t initially contain all of the committed entries.
a voter denies a less up-to-date candidate	the election restriction	[1] §5.4.1 The RequestVote RPC implements this restriction: the RPC includes information about the candidate’s log, and the voter denies its vote if its own log is more up-to-date than that of the candidate.
later last term wins, then longer	which log is more up-to-date	[1] §5.4.1 If the logs have last entries with different terms, then the log with the later term is more up-to-date. If the logs end with the same term, then whichever log is longer is more up-to-date.
never committed by counting replicas	old-term entries	[1] §5.4.2 Raft never commits log entries from previous terms by counting replicas.
a current-term entry on a majority commits	Figure 8 (e)	[1] Figure 8 However, if S1 replicates an entry from its current term on a majority of the servers before crashing, as in (e), then this entry is committed (S5 cannot win an election).
more conservative than necessary, for simplicity	the commit rule	[1] §5.4.2 There are some situations where a leader could safely conclude that an older log entry is committed (for example, if that entry is stored on every server), but Raft takes a more conservative approach for simplicity.
unlike other algorithms	old entries keep their term numbers	[1] §5.4.2 Raft incurs this extra complexity in the commitment rules because log entries retain their original term numbers when a leader replicates entries from previous terms.
same index and term means identical prefix	Log Matching	[1] Figure 3 Log Matching: if two logs contain an entry with the same index and term, then the logs are identical in all entries up through the given index.
committed entries are in every later leader	Leader Completeness	[1] Figure 3 Leader Completeness: if a log entry is committed in a given term, then that entry will be present in the logs of the leaders for all higher-numbered terms.
no two servers apply different entries at one index	State Machine Safety	[1] Figure 3 State Machine Safety: if a server has applied a log entry at a given index to its state machine, no other server will ever apply a different log entry for the same index.
at least one voter both accepted the entry and voted for the later leader	the Leader Completeness argument	[1] §5.4.3 leaderU received votes from a majority of the cluster. Thus, at least one server (“the voter”)
safety properties formally specified and proven	the introduction	[1] Abstract its safety properties have been formally specified and proven
one property, with unchecked invariants	the mechanical proof	[1] §9.2 We have mechanically proven the Log Completeness Property using the TLA proof system [7]. However, this proof relies on invariants that have not been mechanically checked (for example, we have not proven the type safety of the specification).
about 400 lines	the TLA+ specification	[1] §9.2 It is about 400 lines long and serves as the subject of the proof.
average time to send RPCs to every server in parallel and receive the responses	broadcastTime	[1] §5.6 broadcastTime is the average time it takes a server to send RPCs in parallel to every server in the cluster and receive their responses
an order of magnitude	broadcast against timeout	[1] §5.6 The broadcast time should be an order of magnitude less than the election timeout so that leaders can reliably send the heartbeat messages required to keep followers from starting elections
0.5 ms to 20 ms	broadcast time	[1] §5.6 so the broadcast time may range from 0.5ms to 20ms, depending on storage technology.
10 ms to 500 ms	the election timeout	[1] §5.6 As a result, the election timeout is likely to be somewhere between 10ms and 500ms.
several months or more	server MTBF	[1] §5.6 server MTBFs are several months or more, which easily satisfies the timing requirement.
a few orders of magnitude	the election timeout against MTBF	[1] §5.6 The election timeout should be a few orders of magnitude less than MTBF so that the system makes steady progress.
unavailable for roughly the election timeout	after a leader crash	[1] §5.6 When the leader crashes, the system will be unavailable for roughly the election timeout
unsafe	switching configurations directly	[1] §6 any approach where servers switch directly from the old configuration to the new configuration is unsafe.
two independent majorities	direct switch	[1] §6 It isn’t possible to atomically switch all of the servers at once, so the cluster can potentially split into two independent majorities during the transition (see Figure 10).
a transitional configuration	joint consensus	[1] §6 In Raft the cluster first switches to a transitional configuration we call joint consensus; once the joint consensus has been committed, the system then transitions to the new configuration.
separate majorities from both configurations	agreement under joint consensus	[1] §6 Agreement (for elections and entry commitment) requires separate majorities from both the old and new configurations.
join as non-voting members first	new servers	[1] §6 Raft introduces an additional phase before the configuration change, in which the new servers join the cluster as non-voting members
steps down once C_new is committed	a leader not in the new configuration	[1] §6 In this case, the leader steps down (returns to follower state) once it has committed the Cnew log entry.
can disrupt the cluster	removed servers	[1] §6 These servers will not receive heartbeats, so they will time out and start new elections.
ignore RequestVote within the minimum election timeout of a leader	the remedy	[1] §6 Specifically, if a server receives a RequestVote RPC within the minimum election timeout of hearing from a current leader, it does not update its term or grant its vote.
the latest in its log, committed or not	which configuration a server uses	[1] §6 a server always uses the latest configuration in its log, regardless of whether the entry is committed
the first approach the authors came up with	joint consensus	[4] ch. Cluster membership changes This was the first approach to membership changes that we came up with, and it is described only for completeness.
one server at a time	the dissertation's membership change	[4] ch. Cluster membership changes Thus, Raft restricts the types of changes that are allowed: only one server can be added or removed from the cluster at a time.
any old majority overlaps any new majority	a single-server change	[4] ch. Cluster membership changes When adding a single server to a cluster or removing a single server from a cluster, any majority of the old cluster overlaps with any majority of the new cluster
no longer recommended	joint consensus	[4] ch. Cluster membership changes Now that we know about the simpler single-server approach, we recommend that one instead, since handling arbitrary changes requires extra complexity.
still used the complex approach	the authors' own implementation	[4] ch. Cluster membership changes it still uses the more complex approach at the time of this writing.
snapshotting is the simplest approach	compaction	[1] §7 Snapshotting is the simplest approach to compaction.
each server, independently	who snapshots	[1] §7 Each server takes snapshots independently, covering just the committed entries in its log.
last included index and term	what a snapshot records	[1] §7 Raft also includes a small amount of metadata in the snapshot: the last included index is the index of the last entry in the log that the snapshot replaces (the last entry the state machine had applied), and the last included term is the term of this entry.
is sent a snapshot	a lagging follower	[1] §7 The leader uses a new RPC called InstallSnapshot to send snapshots to followers that are too far behind; see Figure 13.
later entries are kept	a snapshot that describes a prefix of the log	[1] §7 If instead the follower receives a snapshot that describes a prefix of its log (due to retransmission or by mistake), then log entries covered by the snapshot are deleted but entries following the snapshot are still valid and must be retained.
departs from the strong leader principle	snapshotting	[1] §7 This snapshotting approach departs from Raft’s strong leader principle, since followers can take snapshots without the knowledge of the leader.
log cleaning and log-structured merge trees	incremental compaction	[1] §7 Incremental approaches to compaction, such as log cleaning [36] and log-structured merge trees [30, 5], are also possible.
connects to a randomly chosen server	a client starting up	[1] §8 that server will reject the client’s request and supply information about the most recent leader it has heard from
retried indefinitely; RPCs are idempotent	follower and candidate crashes	[1] §5.5 Raft handles these failures by retrying indefinitely; if the crashed server restarts, then the RPC will complete successfully.
idempotent	AppendEntries	[1] §5.5 Raft RPCs are idempotent, so this causes no harm.
suppressed with serial numbers	duplicate commands	[1] §8 The solution is for clients to assign unique serial numbers to every command.
lets the leader learn its commit index	the no-op	[4] ch. Client interaction To find out, it needs to commit an entry from its term. Raft handles this by having each leader commit a blank no-op entry into the log at the start of its term.
needs a heartbeat round with a majority	a read-only request	[1] §8 Raft handles this by having the leader exchange heartbeat messages with a majority of the cluster before responding to read-only requests.
rely on timing for safety	lease reads	[1] §8 but this would rely on timing for safety (it assumes bounded clock skew).
43 students at two universities	the user study	[1] Abstract A user study with 43 students at two universities shows that Raft is significantly easier to understand than Paxos
Raft 25.7, Paxos 20.8, out of 60	quiz scores	[1] §9.1 On average, participants scored 4.9 points higher on the Raft quiz than on the Paxos quiz (out of a possible 60 points, the mean Raft score was 25.7 and the mean Paxos score was 20.8)
33 of 43	participants who scored higher on Raft	[1] Figure 14 Points above the diagonal (33) represent participants who scored higher for Raft.
at least 2.5 points larger, at 95% confidence	the paired t-test	[1] §9.1 A paired t-test states that, with 95% confidence, the true distribution of Raft scores has a mean at least 2.5 points larger than the true distribution of Paxos scores.
15 of 43 had Paxos experience; the Paxos video was 14% longer	prior experience	[1] §9.1 The experiment favored Paxos in two ways: 15 of the 43 participants reported having some prior experience with Paxos, and the Paxos video is 14% longer than the Raft video.
33 of 41	self-reported ease	[1] §9.1 An overwhelming majority of participants reported Raft would be easier to implement and explain (33 of 41 for each question).
exceptionally difficult to understand	the complaint about Paxos	[1] §3 The first drawback is that Paxos is exceptionally difficult to understand.
almost a year	understanding Paxos	[1] §3 a process that took almost a year
election, replication, safety	decomposition	[1] §1 including decomposition (Raft separates leader election, log replication, and safety)
a single round-trip from the leader to half the cluster	replicating a new entry	[1] §9.3 Raft achieves this using the minimal number of messages (a single round-trip from the leader to half the cluster).
lower latency than Raft in WAN settings	EPaxos	[1] §10 However, if commands that are proposed concurrently do not commute with each other, EPaxos requires an additional round of communication.
Raft 4; VR and ZooKeeper 10 each	message types	[1] §10 VR and ZooKeeper each define 10 different message types, while Raft has only 4 message types (two RPC requests and their responses).
roughly 2000 lines of C++	the implementation	[1] §9 The Raft implementation contains roughly 2000 lines of C++ code, not including tests, comments, or blank lines.
longer than 10 seconds	with no randomness	[1] §9.3 In the absence of randomness, leader election consistently took longer than 10 seconds in our tests due to many split votes.
median downtime 287 ms	with 5 ms of randomness	[1] §9.3 Adding just 5ms of randomness helps significantly, resulting in a median downtime of 287ms.
worst case 513 ms over 1000 trials	with 50 ms of randomness	[1] §9.3 with 50ms of randomness the worst-case completion time (over 1000 trials) was 513ms.
35 ms on average, longest 152 ms	with 12–24 ms timeouts	[1] §9.3 With an election timeout of 12–24ms, it takes only 35ms on average to elect a leader (the longest trial took 152ms).
repeatedly crash the leader of five servers	the leader-election benchmark	[1] §9.3 To measure leader election, we repeatedly crashed the leader of a cluster of five servers and timed how long it took to detect the crash and elect a new leader (see Figure 16).
timers start together	the synchronized heartbeat	[1] §9.3 Furthermore, to encourage split votes, our test script triggered a synchronized broadcast of heartbeat RPCs from the leader before terminating its process
uniform within the heartbeat interval, half the minimum timeout	the crash	[1] §9.3 The leader was crashed uniformly randomly within its heartbeat interval, which was half of the minimum election timeout for all tests.
different log lengths and a synchronized heartbeat	the worst case they built	[1] §9.3 To generate a worst-case scenario, the servers in each trial had different log lengths, so some candidates were not eligible to become leader.
1000 trials per line; broadcast time roughly 15 ms	Figure 16, trials and broadcast time	[1] Figure 16 The measurements were taken on a cluster of five servers with a broadcast time of roughly 15ms.
1000 (100 for 150–150 ms)	Figure 16, trials per line	[1] Figure 16 Each line represents 1000 trials (except for 100 trials for “150–150ms”)
35 ms on average	a LAN with aggressive timeouts	[4] ch. Leader election evaluation In a real-world LAN, our system was able to elect a leader in an average of 35ms when configured with aggressive timeouts, though we suggest using a more conservative timeout range in practice.
essentially memoryless	each term	[4] §How fast will Raft elect a leader when split votes are possible? In other words, each election term is essentially memoryless
geometric, mean 1/(1 − split rate)	terms to elect	[4] ch. Leader election evaluation The number of election terms required to elect a leader follows a geometric distribution
about 3–8 times the network latency, depending on the cluster	the knee	[4] §How fast will Raft elect a leader when split votes are possible? Once timeout ranges are sufficiently large (about 3–8 times the network latency, depending on the cluster), the curves become linear with a slight upward slope
10–20 times the one-way latency, split rates under 40%	the recommended range	[4] ch. Leader election evaluation We recommend a range that is 10–20 times the one-way network latency, which keeps split votes rates under 40% in all cases for reasonably sized clusters, and typically results in much lower rates.
about one third of the way into the timeout range	with no split vote	[4] ch. Leader election evaluation When no split vote occurs, elections complete about one third of the way into the election timeout range, on average.
a conservative setting is probably best	configuring the timeout	[4] §How fast will Raft elect a leader when split votes are possible? The graphs provide insight into how to configure election timeouts: a conservative setting is probably best in practice.
a range ten times the one-way latency	the dissertation’s advice	[4] §How fast will Raft elect a leader when split votes are possible? Thus, we recommend using a timeout range that is ten times the one-way network latency
elections typically within half a second, 99.9% within 3 seconds	a simulated WAN	[4] ch. Leader election evaluation On a simulated WAN spanning the US, elections typically complete in half a second, and 99.9% of elections complete in 3 seconds, even when two of five servers have failed.
expected 1/(s+1) of the way through the range	the first timeout among s servers	[4] §How fast will Raft elect a leader with no split votes? For example, with four available servers, the first timeout is expected to occur
about 0.06%	split rate, n=5, s=4, 1 ms of 100 ms	[4] §How common are split votes? In about 0.06% of elections, if the one-way network latency is 1ms
about 5.2%	split rate, n=5, s=4, 10 ms of 100 ms	[4] §How common are split votes? In about 5.2% of elections, if the one-way network latency is 10ms
about 18.1%	split rate, n=5, s=4, 20 ms of 100 ms	[4] §How common are split votes? In about 18.1% of elections, if the one-way network latency is 20ms
about half	five servers, two failed, l = 0.2	[4] §How common are split votes? a five-server cluster with two failures and $l=0.2$ will see about half of elections end in split votes.
nearly 70%	nine servers, four failed, l = 0.2	[4] §How common are split votes? However, when it is down to its bare majority with four failures, the nine-server cluster will experience a nearly 70% split vote rate.
10000 runs per point	the dissertation’s simulation	[4] §How common are split votes? After 10000 runs, the fraction of split votes was calculated.
broadcastTime ≪ electionTimeout ≪ MTBF	the timing requirement	[1] §5.6 broadcastTime ≪ electionTimeout ≪ MTBF
violate the timing requirement	timeouts below that	[1] §9.3 However, lowering the timeouts beyond this point violates Raft’s timing requirement: leaders have difficulty broadcasting heartbeats before other servers start new elections.
150–300 ms	the recommendation	[1] §9.3 We recommend using a conservative election timeout such as 150–300ms; such timeouts are unlikely to cause unnecessary leader changes and will still provide good availability.
low timeout and high heartbeat interval encourage leader changes	testing advice	[4] ch. Correctness setting the election timeout very low and the heartbeat interval very high will result in more leader changes.
a candidate increments its term only after a majority says it would vote	Pre-Vote	[4] §Preventing disruptions when a server rejoins the cluster a candidate only increments its term if it first learns from a majority of the cluster that they would be willing to grant the candidate their votes
does not appear to significantly harm it	Pre-Vote and election performance	[4] §Preventing disruptions when a server rejoins the cluster it does not appear to significantly harm election performance.
asymmetric networks, packet loss, clock drift	questions the dissertation leaves	[4] §Conclusion of the leader election chapter How does leader election perform in asymmetric networks, where each link has a different latency?

How this was made

The run is a seeded discrete-event simulation of the rules of the paper's Figure 2, computed in the page by engine.js. test.mjs checks it against Figure 7 (rejections per follower counted by a separate walk down the logs), Figure 8 (panels d and e recomputed), the five properties of Figure 3 on 300 random executions with crashes, partitions, loss and duplication, two deliberately broken rules, the dissertation's closed form against the numbers its text quotes, an exhaustive enumeration of configuration changes against a pigeonhole condition, and the stored research results recomputed from their seeds. Every paper number is a fact with a verbatim quote from the paper, the dissertation or the source code.

Built with the dissection skill. The visual grammar of values as blocks of cells owes much to Brendan Bycroft's LLM Visualization. Source, tests and experiments: anatomy/architecture/2026-10-17-raft/ in the site's repository.

Cite this page

@misc{sigmoid-raft,
  title  = {Anatomy of Raft},
  author = {Praveen T N},
  year   = {2026},
  note   = {Sigmoid Anatomy, interactive dissection},
  url    = {https://praveentn.live/anatomy/raft}
}