Understanding Raft Consensus Algorithm: Distributed Computing

Introduction and Core Concepts

The raft consensus algorithm is a distributed consensus protocol designed to manage replicated state machines in a fault-tolerant manner. Introduced by Diego Ongaro and John Ousterhout in 2014 as a more understandable alternative to Paxos, Raft provides a clear, decomposable approach to achieving agreement among a cluster of unreliable servers. At its core, the raft consensus algorithm ensures that a collection of nodes can agree on a single, consistent log of operations even when individual nodes fail, messages are delayed, or the network partitions.

Consensus is a fundamental problem in distributed systems. When you have multiple servers replicating data for availability and durability, you must ensure they all apply the same sequence of state transitions in the same order. Without consensus, replicas diverge, leading to data inconsistency, split-brain scenarios, and application-level corruption. The raft consensus algorithm solves this by electing a single leader that is solely responsible for managing log replication, dramatically simplifying reasoning about consistency compared to leaderless or multi-leader protocols.

Raft was explicitly designed for understandability without sacrificing correctness or performance. The authors conducted a study where students learned both Paxos and Raft, and Raft was significantly easier to learn and implement correctly. This understandability translates directly into real-world reliability: systems built with Raft are less likely to contain subtle bugs in their consensus logic. The protocol guarantees safety under all non-Byzantine conditions, meaning it will never return an incorrect result as long as nodes fail only by crashing and not by acting maliciously. It achieves liveness with timing assumptions, requiring that a majority of nodes can eventually communicate within bounded delays.

Key concepts that underpin the raft consensus algorithm include the replicated log, terms, and the strong leader principle. Every node maintains a persistent log where each entry contains a command for the state machine and the term when it was created. Terms are logical clocks represented as monotonically increasing integers that act as an epoch number. The strong leader principle dictates that log entries flow in only one direction: from the leader to followers, never the reverse. This single constraint simplifies the protocol and makes it easier to reason about correctness, debugging, and operational monitoring.

• Replicated State Machine: Each node runs a deterministic state machine; consensus ensures all nodes execute the same commands in the same order.
• Fault Tolerance: Raft tolerates failure of up to (N-1)/2 nodes in an N-node cluster, requiring a majority quorum to make progress.
• Understandability: Decomposed into three relatively independent subproblems: leader election, log replication, and safety.

How It Works

The raft consensus algorithm operates by decomposing consensus into three distinct mechanisms that work together to maintain a consistent replicated log. Unlike monolithic protocols, this separation allows each component to be understood, implemented, and tested independently. The cluster moves through terms, each of which may have at most one leader, and all critical decisions require acknowledgment from a majority of nodes.

Leader Election

Every node in a Raft cluster is always in one of three states: follower, candidate, or leader. Followers are passive and only respond to requests from leaders and candidates. If a follower does not receive any communication from a leader within an election timeout (typically 150-300ms, randomized per node), it assumes there is no leader and transitions to candidate. The candidate increments its current term, votes for itself, and sends RequestVote RPCs to all other nodes asking for their vote.

A node grants its vote to a candidate if the candidate's log is at least as up-to-date as its own and it has not already voted in the current term. This log comparison is the critical safety mechanism: it ensures that any committed entry from a previous term will be present on the newly elected leader. If the candidate receives votes from a majority of the cluster, it becomes leader for that term and immediately begins sending periodic heartbeat messages (empty AppendEntries RPCs) to establish its authority and prevent new elections. If it receives a message from a valid leader with a term greater than or equal to its own, it steps down to follower. If the election results in a split vote where no candidate achieves a majority, each candidate times out and starts a new election with a higher term and a new randomized timeout.

Log Replication

Once a leader is established, clients interact only with the leader. When a client sends a command to the leader, the leader appends the command as a new entry to its local log but does not yet apply it to its state machine. It then issues AppendEntries RPCs in parallel to all followers to replicate the entry. When the entry has been safely replicated on a majority of nodes, the leader considers it committed, applies it to its own state machine, and returns the result to the client. It also piggybacks the commit index on subsequent AppendEntries RPCs to inform followers that they can safely apply the entry.

Raft maintains the Log Matching Property: if two logs contain an entry with the same index and term, then the logs are identical in all entries up through that index. This is enforced by a consistency check in AppendEntries: the leader includes the index and term of the entry immediately preceding the new entries, and the follower rejects the request if it does not have a matching entry. When a rejection occurs, the leader decrements the nextIndex for that follower and retries, eventually finding the point where logs diverge and overwriting any conflicting follower entries. This leader-centric replication ensures that followers never create new log entries on their own; they only append what the leader sends.

Safety and Commitment Rules

Safety in Raft means that committed entries are never lost and state machines never diverge. To guarantee this, Raft imposes an additional restriction on commitment: a leader may not consider an entry from a previous term committed simply by counting replicas. It must commit at least one entry from its current term by replicating it to a majority. Once an entry from the current term is committed, all prior entries are indirectly committed because of the Log Matching Property. This rule prevents a subtle scenario where an old, uncommitted entry could be overwritten after a leader change.

Implementation

Implementing the raft consensus algorithm requires careful management of persistent state, RPC handling, and timers. The following Python examples illustrate the core data structures and logic in a simplified, single-threaded simulation. A production implementation would require persistence to disk, true network RPCs, and concurrency control, but the logical flow remains identical.

The first block defines the persistent and volatile state that every Raft node must maintain. Persistent state must be written to stable storage before responding to RPCs to survive crashes, while volatile state can be reconstructed after a restart.

# Raft node state - simplified for clarity
import random
import time
from enum import Enum
from dataclasses import dataclass

class State(Enum):
    FOLLOWER = 1
    CANDIDATE = 2
    LEADER = 3

@dataclass
class LogEntry:
    term: int          # term when entry was created
    command: str       # state machine command (e.g., "x=5")
    index: int         # position in log (1-indexed)

class RaftNode:
    def __init__(self, node_id, peers):
        self.node_id = node_id
        self.peers = peers  # list of other node IDs
        
        # Persistent state (must survive restart)
        self.current_term = 0
        self.voted_for = None
        self.log = []  # list of LogEntry, index 0 is dummy entry term 0
        
        # Volatile state
        self.commit_index = 0
        self.last_applied = 0
        self.state = State.FOLLOWER
        
        # Leader-only volatile state (reinitialized after election)
        self.next_index = {}   # for each peer, next log index to send
        self.match_index = {}  # for each peer, highest replicated index
        
        # Timers
        self.election_timeout = random.uniform(0.15, 0.30)  # 150-300ms
        self.last_heartbeat = time.time()

    def is_log_up_to_date(self, candidate_last_log_term, candidate_last_log_index):
        """Check if candidate's log is at least as up-to-date as receiver's log."""
        my_last_term = self.log[-1].term if self.log else 0
        my_last_index = len(self.log)
        # Raft determines which log is more up-to-date by comparing term, then index
        if candidate_last_log_term != my_last_term:
            return candidate_last_log_term > my_last_term
        return candidate_last_log_index >= my_last_index

The second block implements the RequestVote RPC handler and the election initiation logic. Note the strict voting rules and the term comparison that ensures a node steps down if it discovers a higher term.

def handle_request_vote(self, candidate_id, candidate_term, last_log_index, last_log_term):
        """Follower handles RequestVote RPC from candidate."""
        # If candidate's term is stale, reject immediately
        if candidate_term < self.current_term:
            return {"term": self.current_term, "vote_granted": False}
        
        # If we discover a higher term, step down to follower
        if candidate_term > self.current_term:
            self.current_term = candidate_term
            self.state = State.FOLLOWER
            self.voted_for = None
        
        # Check if we can grant vote: haven't voted or already voted for this candidate
        # AND candidate's log is at least as up-to-date as ours
        can_vote = (self.voted_for is None or self.voted_for == candidate_id)
        log_ok = self.is_log_up_to_date(last_log_term, last_log_index)
        
        if can_vote and log_ok:
            self.voted_for = candidate_id
            self.last_heartbeat = time.time()  # reset election timer
            return {"term": self.current_term, "vote_granted": True}
        
        return {"term": self.current_term, "vote_granted": False}

def start_election(self):
        """Called when election timeout expires."""
        self.current_term += 1
        self.state = State.CANDIDATE
        self.voted_for = self.node_id
        votes_received = 1  # vote for self
        
        last_log_index = len(self.log)
        last_log_term = self.log[-1].term if self.log else 0
        
        # Send RequestVote to all peers in parallel (simulated sequentially here)
        for peer in self.peers:
            response = self.send_request_vote(peer, self.current_term,
                                              last_log_index, last_log_term)
            if response["vote_granted"]:
                votes_received += 1
        
        # Check for majority - need > N/2 votes
        if votes_received > (len(self.peers) + 1) // 2:
            self.become_leader()

The third block shows the AppendEntries RPC, which serves both as a heartbeat and as the log replication mechanism. The consistency check is the core of Raft's log matching guarantee.

def handle_append_entries(self, leader_id, term, prev_log_index, prev_log_term, entries, leader_commit):
        """Follower handles AppendEntries RPC from leader."""
        if term < self.current_term:
            return {"term": self.current_term, "success": False}
        
        # Valid leader with term >= ours, so we recognize it and step down
        if term > self.current_term:
            self.current_term = term
            self.voted_for = None
        self.state = State.FOLLOWER
        self.last_heartbeat = time.time()
        
        # Log consistency check: does follower have entry at prev_log_index with matching term?
        if prev_log_index > len(self.log):
            return {"term": self.current_term, "success": False}
        
        if prev_log_index > 0 and self.log[prev_log_index - 1].term != prev_log_term:
            # Conflict found - delete this entry and all that follow
            self.log = self.log[:prev_log_index - 1]
            return {"term": self.current_term, "success": False}
        
        # Append any new entries not already in log
        for entry in entries:
            idx = entry.index
            if idx <= len(self.log):
                # Overwrite if term differs (leader corrects follower)
                if self.log[idx - 1].term != entry.term:
                    self.log = self.log[:idx - 1]
                    self.log.append(entry)
            else:
                self.log.append(entry)
        
        # Update commit index from leader
        if leader_commit > self.commit_index:
            self.commit_index = min(leader_commit, len(self.log))
            self.apply_committed_entries()
        
        return {"term": self.current_term, "success": True}

def become_leader(self):
        """Initialize leader state after winning election."""
        self.state = State.LEADER
        # Initialize next_index to leader's last log index + 1 for each follower
        for peer in self.peers:
            self.next_index[peer] = len(self.log) + 1
            self.match_index[peer] = 0
        # Send initial empty AppendEntries (heartbeat) to establish authority
        self.send_heartbeats()

The final block demonstrates how the leader replicates client commands and advances the commit index only when a majority has acknowledged an entry from the current term.

def client_request(self, command):
        """Leader handles client command - only leader should be called."""
        if self.state != State.LEADER:
            return {"success": False, "leader_hint": None, "message": "Not leader"}
        
        # Append to own log first
        new_entry = LogEntry(term=self.current_term, command=command, index=len(self.log) + 1)
        self.log.append(new_entry)
        
        # Replicate to followers
        for peer in self.peers:
            self.replicate_to_follower(peer)
        
        # Check if we can commit (majority replication)
        # Only entries from current term can be committed by counting replicas
        for idx in range(self.commit_index + 1, len(self.log) + 1):
            if self.log[idx - 1].term != self.current_term:
                continue
            # Count how many nodes have this entry (including leader)
            count = 1
            for peer in self.peers:
                if self.match_index.get(peer, 0) >= idx:
                    count += 1
            if count > (len(self.peers) + 1) // 2:
                self.commit_index = idx
        
        self.apply_committed_entries()
        return {"success": True, "commit_index": self.commit_index}

def replicate_to_follower(self, peer):
        """Send AppendEntries to a single follower with retry logic."""
        next_idx = self.next_index[peer]
        prev_log_index = next_idx - 1
        prev_log_term = self.log[prev_log_index - 1].term if prev_log_index > 0 else 0
        entries = self.log[next_idx - 1:]  # entries to send
        
        response = self.send_append_entries(peer, self.current_term, prev_log_index,
                                            prev_log_term, entries, self.commit_index)
        
        if response["success"]:
            self.match_index[peer] = prev_log_index + len(entries)
            self.next_index[peer] = self.match_index[peer] + 1
        else:
            # Decrement next_index and retry (log inconsistency)
            if response["term"] > self.current_term:
                self.current_term = response["term"]
                self.state = State.FOLLOWER
                self.voted_for = None
            else:
                self.next_index[peer] = max(1, self.next_index[peer] - 1)

def apply_committed_entries(self):
        """Apply committed entries to state machine in order."""
        while self.last_applied < self.commit_index:
            self.last_applied += 1
            entry = self.log[self.last_applied - 1]
            # apply_to_state_machine(entry.command) - deterministic execution
            print(f"Node {self.node_id} applying: {entry.command} at index {entry.index}")

Step-by-Step Example

Consider a five-node cluster (A, B, C, D, E) that needs to replicate a client command SET x = 5. Initially, all nodes are followers in term 1 with empty logs and an elected leader A. This walkthrough demonstrates leader election after a failure, log replication, and commitment.

Suppose leader A crashes due to a hardware failure. Followers B, C, D, and E stop receiving heartbeats. Each has a randomized election timeout between 150ms and 300ms. Node B's timer expires first at 165ms, so B increments its term to 2, becomes a candidate, votes for itself, and sends RequestVote RPCs to A, C, D, and E with its last log index (0) and term (0). Nodes C, D, and E are still followers in term 1, have not voted in term 2, and find B's log at least as up-to-date as theirs, so they grant their votes. Node A is down and does not respond. B receives 4 votes (including itself) out of 5, achieving a majority, and becomes leader for term 2. It immediately sends empty AppendEntries heartbeats to all nodes to assert leadership; C, D, and E update their term to 2 and reset their election timers.

Now a client sends SET x = 5 to the new leader B. B appends an entry [term=2, index=1, command=SET x=5] to its local log. It then sends AppendEntries RPCs to C, D, and E, each containing prevLogIndex=0, prevLogTerm=0, and the new entry. Nodes C and D receive the RPC, pass the consistency check, append the entry, and reply success. Node E is temporarily partitioned and does not respond. B now has the entry on 3 nodes (B, C, D), which is a majority of 5, so B marks the entry as committed (commitIndex=1), applies it to its state machine (setting x to 5), and replies success to the client. On the next heartbeat, B includes leaderCommit=1, so C and D also apply the entry. When the partition heals, E will be brought up to date via the leader's retry mechanism, which will resend the missing entry after detecting that E's nextIndex is behind.

If instead B had failed to replicate to a majority before crashing, the entry would remain uncommitted and could be overwritten. For example, if B only replicated to C before crashing, the new leader (say D in term 3) might not have the entry and would overwrite it on C when replicating its own entries. This is safe because the client was never told the entry was committed. The rule that a leader must commit an entry from its own term before considering previous entries committed ensures that such uncommitted entries are handled correctly without violating safety.

Complexity Analysis

The raft consensus algorithm is designed for practical efficiency in the common case where a stable leader exists and the network is reliable. Its complexity is dominated by message counts and log size rather than heavy computation. Understanding these costs is essential for capacity planning and for tuning timeouts and batch sizes in production deployments.

In the steady state with a stable leader, replicating a single client command requires one AppendEntries RPC per follower, each containing the new entries. The leader sends these RPCs in parallel, so the latency to commit is a single round-trip time to a majority of followers. This gives O(N) messages per command where N is the cluster size, and O(1) latency in terms of network round trips. If commands are batched, the amortized message cost per command drops significantly, approaching O(N / batch_size).

Leader election is more expensive but occurs infrequently. In the best case, a single candidate wins immediately with O(N) RequestVote messages. In the worst case with split votes, multiple election rounds may be needed. Randomized timeouts make the probability of repeated split votes very low, especially as cluster size increases, but the worst-case message complexity is unbounded without timing assumptions. The time to elect a new leader is typically one election timeout plus one round-trip time, usually 150-400ms in a well-tuned cluster. Log reconciliation after a leader change can require O(log length) RPCs in the worst case if a follower is far behind, but the optimized nextIndex backoff with conflict term optimization reduces this to O(number of conflicting terms).

Space complexity is O(L) per node where L is the number of log entries. In practice, logs grow without bound and must be compacted via snapshotting. Without snapshotting, a long-running cluster would eventually exhaust disk space. With periodic snapshots, the space becomes O(S + L_recent) where S is the snapshot size and L_recent is the log since the last snapshot. All persistent state (currentTerm, votedFor, log) must be written synchronously to disk before responding to RPCs, so disk I/O latency is often the bottleneck rather than CPU or network.

Variations and Optimizations

While the core raft consensus algorithm is elegant and correct, production systems almost always implement several well-known optimizations to improve throughput, latency, and resource utilization. These variations preserve Raft's safety guarantees while adapting it to specific workload characteristics.

Batching and pipelining are the most impactful throughput optimizations. Instead of replicating one client command per AppendEntries RPC, the leader batches multiple commands together and sends them in a single RPC. This amortizes the per-RPC overhead of network headers, disk fsyncs, and consistency checks. Pipelining allows the leader to send the next AppendEntries before the previous one is acknowledged, keeping the network saturated. However, pipelining must be carefully implemented to handle out-of-order responses and to avoid overwhelming a slow follower. Many implementations use a sliding window per follower to limit in-flight RPCs.

Read-only query optimization addresses the high cost of linearizable reads. Naively, a read would need to be written to the log like any other command to ensure linearizability, which is wasteful. Raft provides two optimizations: lease-based reads and quorum reads. With lease-based reads, the leader assumes its leadership lease is still valid for a bounded time after its last heartbeat and can serve reads locally without log replication, provided its clock is well-behaved. With quorum reads, the leader sends heartbeats to verify it is still the leader and then serves the read from its local state machine without writing to the log. Both approaches reduce read latency from O(N) log writes to O(N) heartbeats or even O(1) in the lease case.

Other important variations include Pre-Vote, Joint Consensus for membership changes, and log compaction strategies. Pre-Vote adds an extra phase before a candidate increments its term: the candidate first asks peers if they would grant a vote, and only increments its term if it would likely win. This prevents a partitioned node that rejoins with a stale log from disrupting the stable leader by forcing unnecessary elections with higher terms. Joint Consensus allows safe cluster membership changes by transitioning through a joint configuration where both old and new majorities are required, avoiding availability gaps. For log compaction, many systems implement incremental snapshotting and InstallSnapshot RPCs that can be chunked and throttled to avoid blocking the leader.

Real-World Applications

The raft consensus algorithm has become the de facto standard for building strongly consistent distributed systems, largely due to its understandability and the availability of high-quality open-source implementations. Its strong leader model maps naturally to systems that need a single source of truth for configuration, metadata, or data sharding.

In distributed databases and storage systems, Raft is ubiquitous. etcd, which uses Raft to store configuration for Kubernetes clusters, is perhaps the most widely deployed example; every Kubernetes cluster relies on etcd's Raft log to store cluster state, secrets, and service discovery information. CockroachDB and TiKV use Raft to replicate ranges of data across nodes, providing serializable transactions with automatic failover. Consul uses Raft for service discovery and health checking. In each of these systems, the Raft log is not just for leader election but for replicating the actual data mutations, ensuring that committed writes survive failures.

Beyond databases, Raft is used in message queues, coordination services, and even network infrastructure. For example, distributed locks and leader election for job schedulers are often built on top of Raft-based stores like etcd or HashiCorp Consul. Software-defined networking controllers use Raft to replicate flow table updates consistently across controller replicas. Even in web serving, while the data plane may be eventually consistent, the control plane that manages routing configuration, TLS certificates, and feature flags is frequently backed by a Raft cluster to prevent inconsistent configuration from causing outages.

Choosing Raft is particularly appropriate when you need strong consistency, high availability for reads and writes as long as a majority is available, and operational simplicity. It is less suitable for high-throughput, low-latency global replication where multi-leader or leaderless protocols may be preferred, or for Byzantine fault tolerance where nodes may act maliciously.

Comparison with Alternatives

While the raft consensus algorithm is popular, it is not the only approach to distributed consensus. Understanding its trade-offs relative to Paxos, Zab, and other protocols helps architects choose the right tool for their consistency, availability, and performance requirements. The fundamental trade-off is between understandability, performance characteristics, and the specific failure model.

Paxos is the classical consensus algorithm proven correct by Leslie Lamport. In its basic form, Paxos is leaderless and allows any node to propose values, which can lead to livelock under contention. Multi-Paxos adds a leader to optimize the common case, making its steady-state behavior very similar to Raft. However, Paxos's description is notoriously difficult to understand because it is presented as a single, monolithic protocol with subtle optimizations. Raft achieves the same safety and liveness as Multi-Paxos but with a more modular, leader-centric design that is easier to implement correctly. Performance in the steady state is essentially identical, but Raft's randomized election timeouts are simpler than Paxos's leader election mechanisms.

Zab (Zookeeper Atomic Broadcast) is the protocol used by Apache ZooKeeper. Like Raft, Zab is leader-based and provides strong consistency, but it was designed specifically for ZooKeeper's use case of replicating a hierarchical namespace. Zab differs in its handling of leader election and log replication phases, using a separate discovery and synchronization phase. Raft's log matching property and commitment rules are more general and arguably simpler. Viewstamped Replication (VR) is another leader-based protocol that predates Raft and shares many similarities, but VR's reconfiguration protocol is less well-specified than Raft's Joint Consensus approach. For Byzantine fault tolerance, protocols like PBFT are required, as Raft and Paxos only tolerate crash failures, not malicious behavior.

Common Mistakes and Best Practices

Implementing the raft consensus algorithm correctly is deceptively difficult. While the core logic is understandable, subtle bugs in persistence, timing, and edge-case handling can violate safety or liveness. Production experience from etcd, Consul, and other systems has highlighted recurring pitfalls.

A frequent mistake is failing to persist state before responding to RPCs. Raft requires that currentTerm, votedFor, and log entries be written to stable storage synchronously before acknowledging a RequestVote or AppendEntries. If a node grants a vote and then crashes before persisting votedFor, it may grant the same vote to another candidate in the same term after restart, violating the at-most-one-vote-per-term guarantee and potentially allowing two leaders in the same term. Similarly, acknowledging an AppendEntries before persisting the entries can lead to committed entries being lost after a crash. Always use fsync or equivalent and consider using a write-ahead log with batching to amortize disk I/O costs.

Another common error is mishandling randomized timeouts and heartbeats. Using a fixed election timeout for all nodes guarantees frequent split votes and prolonged unavailability. The randomization must be per-node and per-election, with the election timeout an order of magnitude larger than the heartbeat interval and larger than the typical round-trip time. A best practice is to set heartbeat interval to ~10% of the election timeout (e.g., 50ms heartbeat, 150-300ms election timeout). Additionally, leaders must step down immediately upon discovering a higher term, even if they believe they are still leader; failing to do so can cause a stale leader to commit entries that will be overwritten, violating safety.

Operational best practices include using an odd number of nodes (3 or 5) to tolerate 1 or 2 failures efficiently, monitoring commit latency and election frequency as key health metrics, and implementing robust snapshotting and log compaction. Never place a Raft cluster across more than two availability zones without careful consideration of quorum placement, as a single zone failure could take away a majority. For client interactions, always have clients retry with leader discovery: if a client contacts a follower, the follower should redirect to the known leader, and clients should handle leader changes transparently. Finally, thoroughly test with fault injection tools like Jepsen that simulate partitions, crashes, and clock skew to validate correctness under adverse conditions.

• Persist before ack: fsync currentTerm, votedFor, and log before RPC response.
• Randomize election timeouts per node to avoid split votes.
• Leader steps down on higher term immediately; never commit entries from old terms by counting alone.
• Implement Pre-Vote to prevent disruptive servers from causing spurious elections.
• Use snapshotting to bound log growth and enable fast follower recovery.

Interview Questions

Interview questions about the raft consensus algorithm often test both conceptual understanding and the ability to reason about failure scenarios. Be prepared to discuss not just the happy path but also edge cases around leader changes and commitment.

1. Why does Raft require a leader to commit an entry from its current term before it can consider previous uncommitted entries committed? This tests understanding of Raft's safety mechanism. Answer: Without this rule, a previous leader could have replicated an entry to a majority but not committed it, then a new leader without that entry could be elected (because the new leader's log is considered up-to-date if it has a higher term). If the new leader could commit the old entry by counting replicas, it might commit an entry that will later be overwritten. By requiring the new leader to commit an entry from its current term, Raft ensures that any committed entry must have been present on the leader that committed it, and the Log Matching Property guarantees all prior entries are also present.

2. How does Raft handle a network partition that splits the cluster into two minorities/majorities? Expected answer: Only the partition containing a majority can elect a leader and make progress. The minority partition cannot elect a leader because it cannot achieve a majority of votes, and any existing leader in the minority will step down when it cannot get heartbeats acknowledged and eventually times out, or when it discovers a higher term from the majority partition. This ensures at most one leader per term and prevents split-brain. The minority will be unavailable for writes until the partition heals, which is a fundamental trade-off of CP systems under the CAP theorem.

3. Explain the difference between commitIndex and lastApplied, and why both are needed. Answer: commitIndex is the highest log index known to be committed (replicated on a majority), while lastApplied is the highest index applied to the local state machine. They differ because applying to the state machine can be asynchronous and batched; a node may know an entry is committed but not yet applied it. Separating them allows the Raft log to advance commitment without blocking on state machine execution, which may be slow. Followers learn about commitment via leaderCommit in AppendEntries and then apply entries locally.

4. How would you implement a linearizable read without writing to the Raft log? Answer: Describe quorum reads or lease-based reads. For quorum reads, the leader sends heartbeats to a majority to confirm it is still leader, then serves the read from its local state machine. For lease-based reads, the leader assumes its lease is valid for electionTimeout/2 after last heartbeat and serves reads locally if its clock is monotonic. Both avoid log writes but still ensure the read reflects all committed writes. Mention the need for careful clock handling and that naive local reads on followers are not linearizable.

5. What is the Pre-Vote optimization and what problem does it solve? Answer: Pre-Vote prevents a partitioned node that rejoins with an increased term from disrupting a stable leader. Without Pre-Vote, a node that was partitioned and incremented its term multiple times could, upon rejoining, force the current leader to step down due to higher term, even though the rejoining node cannot win an election because its log is stale. With Pre-Vote, a candidate first asks peers if they would vote for it without incrementing its term; only if it receives a majority of pre-votes does it increment term and start a real election. This avoids unnecessary leader step-downs and improves availability.