The interview question. A three-voter Raft-backed feature-flag service elects leader A in term 9. A has applied every entry in its local committed log. A client asks for a linearizable read, meaning it must observe any successful write completed before the read began. During a partition, B and C might elect a new leader while A remains reachable from the client. Can A safely return its local value? Design a read protocol without appending a log entry for every request.
Assume crash-fault Raft with one fixed membership, durable logs, and the common ReadIndex approach. The local state may already include every committed entry this node knows about. That does not establish that it still has authority to serve a new read. The missing evidence is whether this node is still authoritative at the time of the read.
Think first
A three-node Raft service has an old leader A that is partitioned from B and C but reachable by a client. A is fully applied locally. B and C elect a new leader and commit a changed feature flag. Design a linearizable read from A or a follower without appending a log entry per read. Where does the read barrier come from?
Take a few minutes to form an approach, then compare it with the worked explanation.
Reveal the worked explanation
A perfect local snapshot can be perfectly outdated
A was elected yesterday, has no apply backlog, and serves a value of feature=off. After a network split, B and C can elect a term-10 leader and commit feature=on. A cannot hear them. Its local data structure remains internally consistent, and its last-applied index equals its own known commit index.
Now a customer who already observed successful feature=on reads from A and gets off. For a linearizable API, this is wrong. Applying every entry in an obsolete history does not establish that no later committed entry exists elsewhere.
Local health cannot close that uncertainty. This is the precise problem solved by a read barrier that confirms current leadership before returning a strong read.
A read waits for quorum authority and application through its read index before being answered
Two conditions, not one
A safe Raft ReadIndex path has to establish two facts. First, the read is ordered after a check that the leader still holds valid authority against a quorum. Second, the local state machine has applied enough committed log entries to satisfy the read index selected for that request.
For a typical quorum-confirmed implementation, the leader associates the read with a commit index and confirms that a majority still recognizes its leadership in the relevant term. Once that confirmation is obtained, the leader waits until its state machine has applied at least the read index, then performs the state-machine query.
Applied index alone can authorize an old leader. A quorum check without the applied-index check can authorize a current leader whose local state machine is still behind its committed log. The combined protocol is what matters.
Raft implementations must also handle the leader's initial current-term commitment before serving reads using this method. A newly elected leader cannot always treat an index inherited from an older term as proof that it can immediately serve linearizable reads. Many implementations append and commit a no-op from the new term first. That connects this lesson to the earlier Raft commit exercise without duplicating it.
What does a follower do?
Suppose the client is connected to follower F because it is geographically close. F cannot simply use its local applied index as proof of freshness. It can ask the leader for a safe read index and then wait until F's own state machine has applied through that index. Once both the leader's authority check and F's apply condition hold under the protocol, F can serve the result.
This permits a strong read to be executed from a follower without moving the whole data result through the leader. It does not mean that followers independently promise strong reads whenever their replication lag dashboard says zero.
There is an operational cost. The read may involve peer communication, waiting for apply progress, or falling back to the leader. If quorum is unreachable, the node should not quietly weaken the guarantee and return its local value as if it were strong.
Set a deadline. When the barrier cannot complete, return an explicit failure or unavailable outcome, or use a separately requested weak-read API. Do not relabel a stale result as linearizable merely because the product wants lower latency.
Could we use leader leases instead?
Some implementations offer lease-based reads that avoid a fresh quorum confirmation for each read. If the leader can rely on a suitably bounded clock and lease protocol, it may serve a local read while its lease remains valid. This can improve latency, but the safety case now depends on the time assumptions being met.
The etcd Raft implementation documents both safe quorum-confirmed ReadIndex behavior and lease-based read behavior, and explicitly warns about clock-drift assumptions for the latter. The existence of a lease flag in a library is not enough to claim the fast path is correct under arbitrary pauses, unpredictable clock behavior, or partitions.
If a product tolerates a second of stale data, use a clearly weaker contract, perhaps served directly from nearby replicas with freshness measurements. It is usually wasteful to pay for a linearizable barrier when the consumer needs only a bounded or best-effort view. But "we usually see less than one second of lag" is not itself a strict one-second staleness guarantee.
What I would instrument and test
I would measure read-barrier latency, quorum-confirmation failure rate, waiting time for state-machine application, leadership churn, the proportion of reads that fall back, and the user-visible deadline outcomes. Aggregate p99 alone cannot show which boundary is waiting.
Then test an old leader that remains reachable from a client while the other voters elect a new one. It must not successfully return an outdated value through the strong-read endpoint. Separately pause application of committed entries on a legitimate leader and confirm that the read waits for its state to catch up.
A strong interview answer should say which exact evidence authorizes the read. "Read from the leader" is only a routing instruction. It is not a complete read-consistency protocol.
We have protected elections, commits, external workers, and reads. One more problem remains. What happens when we change the voters themselves while those rules are in use?
Go deeper
Quorum-confirmed versus lease-based reads
The low-latency choices change which assumptions carry the proof. Quorum confirmation is communication-heavy but avoids relying on a local time lease for its safety. Lease-based optimizations require a bounded-time argument and careful behavior when the assumptions fail.
Why the read index can be a moving target
A node may receive more committed writes while a read waits. It does not necessarily need to wait for every future write. It needs to apply through the snapshot boundary established for that read by the protocol.
What linearizability does not promise
A linearizable read need not return an event that has merely been proposed. It must respect previously completed operations and a valid single-object or service ordering under the declared API contract.
Check your reasoning
Show why the old leader can be fully applied yet obsolete.
Require confirmation of current authority with the configured quorum for the safe read path.
Require the chosen read index to be applied before returning the state-machine value.
Explain forwarding to a leader or obtaining a safe index for follower reads.
Distinguish quorum-confirmed ReadIndex from bounded-clock lease-based optimization and weaker stale reads.
Common mistake: Assuming reading from any node calling itself leader is linearizable, or confusing no apply backlog with proof of current authority.
Read the answer explanation
Refuse or wait for a safe authority/read-index check rather than pretending the value is strong. — Current authority and applied state are both required. A fully applied local history may be obsolete.
Apply it elsewhere
A configuration agent wants to read the most recent policy after a control-plane election. Which proof prevents an old controller from serving its own stale policy?
Compare your approach
Use a safe barrier against the currently authoritative replication group plus an applied-state boundary, rather than a local leader flag.
One more constraint
When could a lease-based strong read be cheaper, and which clock or pause assumptions must be justified?
Quick revision
An old Raft leader can be fully applied locally yet stale after another majority elects a new leader. A linearizable read therefore needs current-authority evidence, such as a quorum-confirmed ReadIndex check, as well as local application through the chosen read index. Followers can obtain the safe index from the leader and wait for their state machines to apply it. Lease-based optimizations replace some quorum communication with justified bounded-clock assumptions. If the strong-read check cannot complete within the deadline, return unavailability rather than an unlabeled stale result.
