Skip to content

CONCEPT Cited by 2 sources

Leader lease

Definition

A leader lease is a time-bounded grant to the current leader during which no leadership change will occur. While the lease is valid, the leader can safely serve reads locally without a quorum round-trip — any outstanding concurrent elector cannot steal the role until the lease expires. Leases are renewable: a steady-state leader extends its lease as it processes writes, which converges to arbitrarily long stability under normal operation.

Sugu Sougoumarane's framing (Part 5):

"Relying on locks lets us exploit the time component to give leaders a lease, thereby guaranteeing no leader change during the lease period. This lets the users perform efficient, consistent reads by accessing the leader without the need for a quorum read. The existing leader could continue to renew the lease as it completes more requests, which leads to prolonged stability." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races)

Why it only works under lock-based election

Leader leases are coherent only in the lock-based family (patterns/lock-based-leader-election). Under lock-free election there is no stable leader — a newer-proposal-number elector can arrive at any moment and supersede the current one — so no lease can be granted. Sugu explicitly:

"The disadvantage of a lock-free approach is that there is no certainty of a stable leader. This is because it is possible for a leadership to end between the time you discover it and give it a request. The absence of a stable leader makes consistent reads complicated. We essentially have to resort to quorum reads."

The lock-based vs lock-free choice therefore determines whether consistent reads cost a quorum round-trip or a single local read — a dominant component of the cost structure of a read-heavy consensus system.

Clock-skew considerations

Leader leases inherit the clock-sensitivity of the lock-based family. Sugu's concrete numbers:

"In lock-based systems, we have to rely on accurate clocks. The system also has to make sure that sufficient tolerances are built into timeouts to account for normal clock skews, which are typically in the milliseconds. In general, it is advisable to use 'many seconds' of granularity to sequence events."

Millisecond-order skew + second-order sequencing granularity gives a safety margin on the order of 10³ — enough that routine clock drift cannot cause two electors to both believe they hold a valid lease. Spanner's TrueTime solves the same problem with tighter bounds at the cost of GPS + atomic clocks; Sugu's recommendation is the bias-margins-upward version for commodity clocks.

Reuse of the lock time-component

The same time-component that solves forward progress (auto-release the lock if the holder crashes) serves dual duty as the lease expiry. The elector is the leader in many implementations, so the lock-with-timeout is the lease.

Canonical instance: Vitess

Vitess runs lock-based leader election via an etcd-backed coordinator lock, and leverages the resulting stable-leader guarantee to publish the current leader through its topology:

"In Vitess, the current leader for each cluster is published through its topology, and a large number of workflows rely on this information to perform various tasks. Any operation that does not want the leader to change just has to obtain a lock before doing its work."

This is a production instance of the pattern: external workflows acquire the lock (reserving the lease) to freeze the leader for the duration of their work (backups, schema changes, routing reconfiguration).

Seen in

Last updated · 347 distilled / 1,201 read