CONCEPT Cited by 1 source
Quorum read¶
Definition¶
A quorum read is a read that contacts a majority (or durability-defining quorum) of followers to determine the most recent durable value. It is the general-purpose mechanism for delivering consistent reads in systems that do not have a stable leader with a lease.
Sugu Sougoumarane's canonical wiki framing: "A leader could respond to the client with a success message as soon as it has become durable. However, it has the option of delaying the acknowledgement until it has also sent the completion message to the followers. Waiting until completion costs two round-trips and is therefore slower than an early response. On the other hand, it improves the performance of quorum reads. This trade-off may be necessary for systems that choose to implement reads using the quorum method." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-6-completing-requests).
Why quorum reads exist¶
Consensus systems without a stable published leader (lock-free election shapes — Paxos classic, Raft at the abstract-algorithm level) cannot route reads to "the leader" with confidence. Any single node might be stale or about to be superseded. The only way to see the latest durable value is to probe enough followers that at least one of them must have it.
This is the quorum read: contact ≥ durability threshold followers, find the newest value any of them has accepted, return that. The round-trip cost is paid per read.
The interaction with commit-path design¶
Sugu's key observation: commit-path timing affects quorum-read performance.
- Early-ack on durability — client gets ack at the durable stage. Reads later need to discover this write, but the
completemessages haven't propagated yet. A quorum read has to reconcile tentative-and-durable-but-not-yet-complete records — more work. - Late-ack on completion — client gets ack only after
completehas propagated. Reads find already-materialised values. Quorum reads are simple: pick the latest by version / timestamp / log position.
Systems that rely on quorum reads as their primary consistency mechanism therefore prefer the late-ack variant of the two-phase completion protocol — one extra commit-path round-trip for a much cheaper read path.
The lock-based alternative¶
Systems using lock-based leader election with a leader lease can skip quorum reads entirely: "For systems that use lock-based failovers, reads can be sent to the current leader instead of performing quorum reads." The lease guarantees no concurrent leader exists, so leader-local reads are authoritative.
This is Sugu's closing argument in favour of lock-based election: quorum reads dominate the cost structure at scale, and the lease side-steps them entirely.
Trade-off summary¶
| Read strategy | Requires | Per-read cost | Consistency model |
|---|---|---|---|
| Leader-local + lease | Lock-based election, valid lease | 1 local call | Strong (lease-gated) |
| Quorum read | Durability-threshold followers reachable | 1 broadcast + wait | Strong |
| Follower read, no quorum | Nothing | 1 local call | Eventual (stale reads possible) |
Quorum reads are not the most efficient — they are the most generally-applicable when a lease is not available.
Seen in¶
- sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-6-completing-requests — canonical wiki introduction; Sugu uses quorum reads as the foil to motivate the early-ack-vs-late-ack trade-off and to argue for the lock-based election + lease combination.
Related¶
- concepts/consistent-read — the property quorum reads deliver.
- concepts/leader-lease — the alternative mechanism that skips the quorum round-trip.
- concepts/durable-request — the stage at which early-ack happens.
- concepts/two-phase-completion-protocol — the commit path quorum reads interact with.
- patterns/early-ack-on-durability — the latency optimisation that forces quorum reads.
- patterns/lock-based-leader-election — the alternative that skips them.