Lease Read

A configuration store on a 5-node Raft group serves 50,000 reads per second against 2,000 writes. Reads must be linearizable. The leader cannot simply read its own memory and answer: it may have been deposed by a quorum it cannot see, in which case a new leader is already committing writes this one has never heard of, and its "current" value is stale.

There are three honest ways out. Put every read through the log, which turns 50,000 reads per second into 50,000 consensus rounds and durable writes. Use ReadIndex: confirm leadership with a heartbeat round to a quorum, then read local state - one round trip per batch of reads. Or hold a lease: having won an election, no other leader can be elected until a full election timeout has passed without heartbeats, so the leader may serve local reads inside that window, minus the maximum clock error, with no messages at all.

Why it matters

Read paths dominate most consensus workloads by an order of magnitude, and the naive correct answer - a log entry per read - costs a disk write per read. The read path is where consensus systems are made usable or unusable, and the three options above are the entire design space.

The lease option is the only one with no network cost, and it is also the only one that moves a correctness guarantee onto a clock assumption. Knowing that trade exists, and being able to say which assumption your deployment can honour, is the difference between choosing it and inheriting it from a default.

Implementation patterns

• Track the last successful heartbeat round - the point at which a majority acknowledged - and serve local reads only until that time plus the election timeout, minus the maximum clock offset. The subtraction is the safety margin and it is not optional.
• ReadIndex as the default, lease reads as the optimisation. The Raft dissertation (2014) presents both, and the ordering is deliberate: ReadIndex is safe without clock assumptions.
• Clock-drift guard with teeth. Monitor measured offset between members and have a node refuse to serve lease reads, or shut down, when it exceeds the configured bound. CockroachDB's documented default treats 500 ms as the maximum offset and has a node terminate itself past 80% of it.
• Disable lease reads where the clock cannot be trusted - shared virtual machines subject to live migration, environments without a reliable time source, or hosts that are suspended and resumed. A machine that resumes with a stale clock believes a dead lease is live.
• Follower reads as a separate tier, with an explicit staleness bound, for the large fraction of reads that never needed linearizability.

Industry example

etcd implements both: linearizable reads go through a ReadIndex confirmation by default, and serializable reads skip it and may be stale. TiKV documents lease-based reads as an optimisation over ReadIndex, with the lease derived from the election timeout. CockroachDB's leaseholder design is the same idea applied per range, with the maximum-offset guard above as the enforcement mechanism.

The pattern that these have in common is worth stating: the systems that offer lease reads all ship an explicit clock-offset enforcement mechanism alongside them. A lease read without that guard is not the same feature.

Failure scenarios

• A suspended and resumed virtual machine resumes believing its lease is valid, and serves reads from a state another leader has already superseded.
• Clock skew beyond the configured bound on one member, which is invisible on the data path and shows up as a read that contradicts a write the client made.
• A margin set to zero by a well-meaning tuning change, removing the only thing that made the lease safe.
• Lease reads kept on during a network partition where the leader is on the minority side - check-quorum, which steps a leader down when it cannot reach a majority, is the companion control, and lease reads without it are unsafe.
• Silent staleness. Every failure here returns a plausible value rather than an error, so nothing in the system complains and the symptom is a user-visible inconsistency with no log line.

Trade-offs

When not to use it

When the clock cannot be bounded by the platform, use ReadIndex - one round trip to a quorum is cheap insurance against a silent correctness failure.

More often, the reads did not need linearizability in the first place. Most metadata reads are followed by a write that will be validated anyway, so a compare-and-swap on the write path gives the safety the strict read was protecting, and the read can come from a follower at a fraction of the cost. Reach for a lease read only once you have established that strictly fresh reads are a requirement rather than a habit.

Interview question

Q: Your team wants to remove the round trip from a Raft store's linearizable read path by enabling lease reads. What do you need to be true about the deployment before you agree, and what would you monitor afterwards?

What a strong answer covers: the election-timeout window and the need to subtract maximum clock error; check-quorum as a prerequisite so an isolated leader cannot serve its lease; a reliable time source and a measured offset metric with an enforcement action; the virtual-machine suspend-resume hazard; the fact that every failure here is silent and returns a plausible value; and the prior question of whether the reads need linearizability at all.

Quick check

Quiz: What exactly makes a lease read linearizable without any network messages? No other leader can be elected until an election timeout passes without heartbeats, so inside that window minus the maximum clock error, the leader's local state is known to be current.

Flashcard: What does a lease read trade for the round trip it saves? A correctness dependency on bounded clock drift between members - which is why it ships with an offset guard that stops or kills the node.