Why Raft Guarantees Linear Consistency in Unreliable Networks

Problem Overview

Distributed systems often suffer from unreliable networks, unstable clocks, and node crashes, which can cause divergent state among replicas. A three‑node cluster example shows that network delays, disconnections, or packet loss may lead to inconsistent values of a shared variable.

Raft Algorithm Overview

Raft is a consensus protocol that provides linear (strong) consistency using a single‑leader replication model. It defines three node roles— Follower , Candidate , and Leader —and a term‑based election process.

Node Roles and Election

All nodes start as Followers and wait for a heartbeat from a Leader. If a heartbeat times out, the node becomes a Candidate, increments its Term, votes for itself, and requests votes from other Followers. When a Candidate receives votes from a majority of nodes, it becomes the Leader and begins sending periodic heartbeats to maintain authority. Randomized election timeouts prevent livelocks caused by simultaneous elections.

Write Path

All client write requests are handled by the Leader. The Leader appends the command to its write‑ahead log (WAL) in order, assigning a log_index. The log entry must be persisted to stable storage before replication.

The Leader then replicates the entry to Followers via RPC. Once a majority of nodes have stored the entry, the entry is considered committed . The Leader updates commit_index and includes it in subsequent heartbeats.

Committed entries are applied to the state machine in order. The state machine executes the command (e.g., updating variable A), updates its internal state, and returns the result. Application proceeds until apply_index equals commit_index.

Drawbacks of the single‑leader model:

Write scalability is limited because all writes funnel through one node.

If the Leader crashes, a new Leader must be elected, causing a brief downtime.

Read Path

Raft guarantees linear‑consistent reads via two mechanisms.

ReadIndex Read

Store the current commit_index locally as read_index.

Send a heartbeat to other nodes to reaffirm leadership.

Wait until the state machine’s apply_index reaches or exceeds read_index.

Return the read result.

Followers forward read requests to the Leader, which follows the same steps.

Lease Read

To avoid the extra heartbeat, the Leader can use a lease. The lease expiration is computed as:

lease_end = current_time() + election_timeout / clock_drift_bound

If a read arrives before lease_end, the Leader serves it directly after confirming apply_index >= commit_index, eliminating the additional round‑trip.

Consistency Models

Raft provides linear (strong) consistency, the strictest model where every operation appears atomic and globally ordered. For comparison, other common models are:

Sequential Consistency : Preserves program order per client but allows different clients to observe operations in different orders.

Causal Consistency : Requires causally related operations to be seen in order; unrelated concurrent operations may be observed in any order.

Eventual Consistency : Guarantees convergence only after the system becomes quiescent, offering higher performance at the cost of temporary staleness.

CAP theorem: Consistency (C) – every read sees the latest write; Availability (A) – every request receives a response (not necessarily the latest); Partition tolerance (P) – the system continues operating despite network partitions.

Split‑Brain Prevention

During network partitions, Raft’s majority rule ensures that at most one Leader can exist. Additional safeguards include:

Term mechanism : A new term forces old Leaders to step down.

Active step‑down : A Leader voluntarily relinquishes leadership if it cannot contact a majority.

Strict voting rules : Each node may vote for only one candidate per term.

Deployments typically use an odd number of nodes (e.g., three) to avoid ties; adding a fourth node does not increase fault tolerance but raises cost.

Prerequisites for Using Raft

Servers may crash or stop, but they must eventually recover; Byzantine faults are not tolerated.

Messages may be lost, delayed, reordered, or duplicated; network partitions may occur but will heal later.