Raft Leader Leases and Linearizable Reads

A lease removes a read-path round trip by adding a timing assumption to Raft's log guarantees, which also requires explicit commit and read rules during leader changes.

The round trip on every read

Raft guarantees write linearizability through log replication, but reads do not inherit that guarantee without an additional mechanism. A stale leader is a former leader that still believes it is the leader after being demoted to follower. If that node answers from its local state, the client receives a value that does not reflect writes the new leader has already committed.

The standard remedy is a quorum check: on every read, the leader confirms with a quorum that it is still the valid leader. Raft implementations usually expose this under the name ReadIndex. It is correct, but it adds one network round trip to every single read.

The cost does not stop at one round trip. The LeaseGuard paper by Davis, Demirbas, and Deng (arXiv:2512.15659, SIGMOD 2026) measured it directly. The subject was LogCabin, the reference implementation of Raft.

With network delay at 10ms, read latency under quorum reads stretched to 16 seconds because of queueing effects. Round-trip delay caused requests to pile up, and the backlog in turn amplified the delay.

The third row is the subject of this post. It keeps the leader-based structure intact and drives the read path to zero round trips, and this post traces where that cost moves instead.

What makes a lease valid

A leader lease skips the quorum check on the grounds of time. A conventional exclusive lease must prevent another leader from committing writes during its valid interval. LeaseGuard permits leaders from multiple terms to serve reads concurrently, but requires every answer to reflect the latest committed state in the replica set.

The leader serves reads locally only after securing an interval in which no other leader can be elected for the next Δ. The original form proposed by Ongaro in 2014 treats the leader as holding a lease from the moment a quorum of RPCs succeeds within the election timeout. That definition is where the trouble starts later.

The value chosen for the lease duration Δ is tied to the election timeout (ET). If Δ is shorter than ET, the lease breaks often and the window for local reads shrinks. If Δ is longer than ET, a new leader spends more time waiting without a lease. LeaseGuard recommends aligning the two at Δ = ET.

Expiry is not decided against a single point in time. Each node assumes a bounded-uncertainty clock that works with interval timestamps of the form [earliest, latest]. If the recorded time of an entry is e, the lease is definitely expired only when e.latest + Δ is smaller than the earliest of the current time. In an environment where the error bound is unknown, that comparison does not hold at all.

flowchart TD
    R[Read request arrives] --> C{Last committed entry<br/>within Δ}
    C -->|Yes| L[Answer from local state<br/>zero extra round trips]
    C -->|No| W[Quorum check or<br/>wait for lease renewal]
    W --> L

Where leases break

A lease does not fail loudly. While the valid intervals of two leaders briefly overlap, a stale value simply goes out looking like a normal response.

The first path is clock error between nodes. What follows is what happens when a node whose clock runs fast by e declares the lease expired first.

Lease of leader A   [T0, T0+Δ]   (by A's clock)
Clock of node B     runs ahead of A by e
 
  B: declares expiry at T0+Δ-e -> starts an election -> becomes the new leader
  A: believes it is the leader until T0+Δ and answers reads locally
  During the overlapping interval e, two leaders serve reads at once

The second path is message delay. Suppose the lease starts when quorum responses arrive. The delay between sending the request and receiving the response then falls outside the lease interval. HashiCorp Raft still omits this term, and the consistency violation reported in 2016 remains unfixed as of 2025.

The third path has nothing to do with clocks. If a GC pause or scheduling delay lands between the lease validity check and the actual response, the node answers on the grounds of a lease that has already expired. Whenever the lease time remaining at the moment of the check is shorter than the pause, the invariant is violated outright.

The LeaseGuard paper identifies the common cause as an ambiguous specification. The original description of leases was prose only, with no formal specification. Each implementation therefore interpreted expiry computation and lease handover during a leader change differently.

Log-entry-based leases

LeaseGuard adds no lease-specific message and no lease-specific data structure. It grounds the lease in a property Raft already guarantees, Leader Completeness. That property states that a newly elected leader holds every earlier log entry a quorum replicated.

The leader records an interval timestamp alongside each log entry. If the last committed entry is within Δ, every later-term leader has that entry by Leader Completeness. LeaseGuard prevents a later leader from advancing commitIndex until the entry is older than Δ, so a former leader's local read cannot race with a newly committed write.

Lease safety needs a time-error bound, but the clock requirement depends on the feature. Basic leases and Deferred Commit Writes can use local timers with a known maximum drift ε over Δ. Inherited Lease Reads compare times recorded by different nodes and therefore require bounded-uncertainty intervals that contain true time.

The paper evaluated AWS TimeSync with PTP and observed average clock error below 50µs. That is a measurement of its environment rather than a precision guarantee for every deployment.

The verification method differs as well. LeaseGuard specifies the protocol formally in TLA+ and checks correctness theorems along with it. Those theorems include Read-Your-Writes, which states that every read observes the effect of preceding writes. Read At Highest commitIndex, which states that a read reflects the newest state of the replica set, is included too.

The gap right after a leader change

Lease-based reads cost little during steady state. The cost shows up at the moment the leader changes. A new leader is safe only after waiting for the old leader's lease to expire. If it can do nothing while waiting, writes and reads stop together. TiDB going unavailable for 10 seconds after an election is the extreme case of this gap.

LeaseGuard fills the gap in two ways. Deferred Commit Writes lets the new leader accept writes even while waiting and replicate them to followers. Only the commitIndex update is deferred until the old leader's last entry passes Δ. The moment the lease opens, the commit can be confirmed immediately with no additional communication.

Inherited Lease Reads let the new leader inherit the old leader's lease and serve reads immediately. The old leader's last committed entry must not yet have passed Δ. Entries above the commitIndex at election time and below the election index form the limbo region. For those, the new leader cannot know how far the old leader committed. For keys caught in that range, safety comes from reading several versions under multi-version concurrency control (MVCC) and comparing them.

Both optimizations came out of exploring the TLA+ specification. The paper describes the limbo region problem as something the formal specification itself surfaced, which makes the specification a design tool rather than an after-the-fact check.

The measurements ran on three AWS EC2 m7g.xlarge nodes (us-east-1, average ping 155µs), with about 1,600 lines modified out of roughly 27,000 in LogCabin.

How much availability comes back depends on the workload. Experiments shifted the read distribution to Zipfian. A uniform distribution (a=0) succeeded at 3,000 reads per second, while a distribution concentrated on a few keys (a=2) dropped below 500 per second. The more reads converge on keys caught in the limbo region, the less the inherited lease helps.

How far to extend the lease

The first criterion is the clock infrastructure. In an environment where the error bound cannot be measured, using a quorum check instead of a lease is the correct call. Turning on a lease without knowing the bound means violations go undetected when they occur.

The second is the shape of the workload. The higher the read share, the more the removed round trip is worth. A write-heavy workload gains less, because the quorum check accounts for a smaller portion of the total cost. On top of that, consider whether a read gap of Δ right after a leader change is acceptable.

Whether the lease goes to a single leader is also a choice. Moraru, Andersen, and Kaminsky distributed the lease across a quorum of nodes with Quorum Leases at ACM SoCC 2014. Any node holding a lease can serve linearizable reads locally. However, every node holding a lease on that data must confirm a write. If one of them is slow, the whole write is slowed by that much.

Bodega generalizes the lease target to an arbitrarily designated set of responders. Hu, Arpaci-Dusseau, and Arpaci-Dusseau published the design on arXiv in September 2025 (arXiv:2509.07158). Cluster metadata called the roster tracks both who the leader is and which nodes serve local reads.

The mechanism that maintains consensus on that roster is the roster lease. From this angle, a leader lease is the special case where the lease-holding set is fixed at one node.

What shows up in practice is usually the first row. As with sofa-jraft offering ReadIndex and LeaseRead side by side, many implementations keep quorum checks and lease reads as options and let the operator pick. Moving down the rows brings reads closer, at the cost of a heavier write path and heavier reconfiguration logic.

Summary

A leader lease removes one read-path round trip by adding a timing assumption to Raft's log guarantees. Lease calculations that omit message delay or execution pauses can misjudge the valid interval. LeaseGuard makes the transition explicit by coupling log-entry time with a restriction on later leaders' commits.

In the paper's evaluation, its two optimizations raised post-election write throughput from about 1,000 to about 10,000 writes/sec and restored read availability to about 99%. A known drift bound is enough for the basic lease, while inherited reads require bounded-uncertainty clocks across nodes. Adoption therefore depends on the needed feature, clock guarantees, and the gap allowed during a leader change.