Skip to content

CONCEPT Cited by 2 sources

Consistent read

Definition

A consistent read is a read that observes every write committed before it — no stale state, no lost acknowledged updates. Achieving consistent reads in a replicated / consensus system is non-trivial because replicas can be out of date, and the leader itself might be deposed between the client discovering it and issuing the read.

Two implementation shapes dominate, and they correspond directly to the two leader-election families from Sugu Sougoumarane's Part 5:

Shape 1: Leader-with-lease read (lock-based)

Under lock-based election with a valid leader lease, the leader can serve reads locally with no quorum round-trip. The lease guarantees no concurrent leadership change, so the leader's state is authoritative for the duration.

Sugu's framing:

"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." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races)

Canonicalised as patterns/lease-based-consistent-read.

Shape 2: Quorum read (lock-free)

Under lock-free election, there is no stable leader — a leadership can end "between the time you discover it and give it a request" — and so consistent reads must take a quorum round-trip: the reader contacts a majority of replicas and takes the largest committed state they agree on, which is guaranteed to observe any prior-committed write.

Sugu's framing:

"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."

Why the distinction dominates cost

At scale, reads massively outnumber writes. A quorum read costs at least one RPC fan-out + majority-wait per read; a lease-backed read costs one local lookup. The cost ratio can be 10× – 100× depending on replica count and network RTTs. This is the primary reason Sugu recommends the lock-based family at large scale:

"Weighing these options, a lock-based system should be preferred for large scale consensus systems. Having a stable leader simplifies many other operational parts of the system."

Caveats

  • Lease-based consistent reads assume clock safety margins hold. A two-leader split caused by clock skew beyond the margin would violate consistency. Spanner's TrueTime is the extreme-engineering response.
  • Quorum reads have their own subtlety (read-your-writes on a slow follower, read-majorities vs lease-majorities) that Sugu does not unpack in Part 5.
  • Consistent reads are distinct from linearizable reads (reads return a value on the linearisation timeline of writes) — linearizability is a stricter property; consistent-read systems often provide something weaker (sequential consistency, single-register linearizability) depending on details.
  • Soft leader election does not offer consistent reads at all — the two-owner-during-transition failure mode means a read from the "current" owner can observe the wrong state. Soft leader election serves affinity, not consistency.

Seen in

Last updated · 347 distilled / 1,201 read