Linearizable reads: prove authority and wait for application

A linearizable read must correspond to a legal state at some point between its invocation and response, respecting writes completed before it began. It need not include every concurrent write that finishes before the response if a valid earlier linearization point exists. This distinction prevents an impossible requirement that the result remain newest while the response travels. What is unsafe is an old isolated leader returning state that already predates a completed write when the read was invoked.

One simple safe baseline treats a read as an ordered operation through the replicated log, then applies through its position before querying. A more efficient approach uses the leader's committed prefix and a quorum authority check. At the start of a term, the new leader can contain committed entries without yet knowing the full commitment boundary. It first commits an entry from its own term, commonly a no-op, so the earlier prefix is established before it uses the read optimization.

For an appropriately accumulated read request, the leader records a committed read index R and obtains a fresh quorum confirmation of its leadership in the relevant term. Requests and responses must be correlated so old acknowledgements cannot satisfy a newer read round incorrectly. The current-term commitment prerequisite and quorum check together establish a safe boundary under the protocol's assumptions. Batching can amortize one confirmation across requests accumulated before that round; it does not permit arbitrary future reads to reuse an indefinitely old confirmation.

Before querying, the serving replica waits until its state machine has applied at least R. A follower can serve the actual query only after obtaining a safe read index from the leader and catching its own state machine up to that boundary, under the implementation's protocol. Merely knowing that R is committed does not make unapplied state fresh enough. Snapshot installation, concurrent application, and query execution must expose a coherent state-machine view, so a query cannot observe half of an applied transaction.

A lease can reduce per-read communication by asserting a bounded period in which a newer leader cannot validly take over. That assertion requires a proved relationship between clock rates, election behavior, pauses, and lease expiry, not just synchronized-looking wall clocks. Leadership transfer can end the relevant authority earlier and must invalidate the lease appropriately. If clock or timing assumptions fail, the optimization can return stale reads even while the underlying log protocol remains safe. Prefer an explicit lease proof to treating a recent heartbeat timestamp as self-evident authority.

Use the queue lab for the application gate only. Reset, explicitly set arrival zero and service two, predict that four pending items drain in two seconds, then Play or Step. For a separate slower run Reset and explicitly set arrival zero and service one before predicting and playing. Rate changes retain elapsed time and recompute from four initial items, rather than preserving the old backlog. The animation has no quorum messages, read index, leader lease, or coherent database snapshot; it shows only how outstanding work can delay an already justified read boundary.