AI Infrastructure
Quorum Protects Coordination State, but the Read Mode Still Matters
For etcd v3.6, voting quorum and client read mode answer different parts of a coordination-service offer. A majority supports agreement on state changes. A successful default current read of a key must respect a write completed to that key before the read began; an expressly serializable member-local read can return earlier committed state. Member count alone therefore establishes neither the application's read freshness nor its service continuity.
Identify the state being coordinated and the read being promised
A proposal describing three replicated members leaves a practical question unanswered: what will the application learn when it reads after an acknowledged change? The machines might participate in a sound agreement protocol while the offered read path permits an older answer.
This article uses the etcd v3.6 documentation as a named implementation. Its FAQ describes a distributed key-value store intended for small amounts of coordination data. Think of a small key identifying a release selection; the model weights and dataset artifacts are separate resources.
The buyer needs both a voting interpretation and a client-visible read interpretation. The first concerns the members needed for agreement. The second concerns where a read fits relative to completed changes. A replica count supplies no read-mode selection.
References: [EQ1]
Three voters need two; four need three; five need three
For this comparison, n is the fixed, stipulated number of voting members. Majority is floor(n/2) + 1: divide n by two, round down, then add one. This counts votes required for agreement, not client connections or copies of a model.
With three voters, floor(3/2) + 1 = 2. Losing one leaves two, enough for the numerical threshold. With four voters, floor(4/2) + 1 = 3. Losing one leaves three; losing two leaves only two, below the threshold. With five voters, floor(5/2) + 1 = 3. Losing two leaves three.
The simplified failure budget is n minus the required majority: one, one and two member failures respectively. Adding a fourth voter to the comparison does not buy a second tolerated member failure. The additional voter also raises the majority from two to three.
The denominator remains the stipulated voting membership when a member becomes unreachable. Two reachable voters in a four-voter service are two of four, not a newly defined two-of-two majority.
A majority contains more than half the fixed voters, so two disjoint groups cannot each contain a majority of that same membership. This explains the arithmetic behind quorum. Whether the remaining members can communicate and the service can make progress remains essential. These counts establish neither independence from shared power or network failures nor a recovery duration or availability percentage.
References: [EQ1]
A current consensus read and a member-local read make different promises
The etcd v3.6 Range documentation distinguishes default linearizable reads from the optional serializable mode. A default current Range read reflects cluster consensus. The serializable option serves a member's local view without obtaining current consensus for that request, so that view may lag.
Linearizability places an operation at a point between its invocation and response, consistent with the real-time order of operations that do not overlap. A read begun after a completed write to the same key must respect that write. If another write overlaps the read, the result needs reasoning about that history; latest at the instant the response arrives is not the general definition.
Current also needs to mean a current-state request. The Range API can explicitly request an earlier revision. Retrieving that history is a different task from asking for the present value. QR-224 below excludes historical requests and application caches.
The product's serializable option must not be confused with the stronger default strict serializability described in the API guarantees. Selecting that read option permits a weaker freshness result. A member-local read can also be fully up to date; possible staleness is permission, not a prediction that every such read will lag.
QR-224: one completed change, then one current read
Consider fictional coordination key QR-224. Its initial committed value is A. A writer changes that same key to B and receives the successful server response establishing completion. Only after that response does a reader begin an etcd read for the key.
Stipulate that there are no concurrent or later mutations, including deletion or expiry. The request seeks the current value, not a historical revision, and the answer comes from etcd rather than an application cache. These assumptions make the ordering unambiguous.
If the read uses the default linearizable mode and succeeds, its value must be B. Returning A would place the read before the already completed B change, contrary to their real-time order. A successful read cannot replace that freshness obligation with an older answer merely because some member has not caught up.
Now keep the write history unchanged and change the offered read contract. Stipulate that a member's local applied view still contains the earlier committed A. An expressly serializable read served from that lagging view may return A.
That A is a whole, previously committed value. It is not evidence that the reader saw part of the B write or data that was never committed. The difference is the relationship between the returned state and the completed write history.
Neither case is an observed test result. They are consequences of the stated contracts and premises. The contrast does not depend on counting more replicas: the same three-member description is compatible with either offered read mode.
Freshness changes what counts as continued service
Suppose the application requirement for QR-224 is that a successful lookup begun after the B acknowledgement must select B. An offer permitting the serializable A result does not meet that requirement, even though the response is successful and the returned data is committed.
An application with a different purpose may accept an earlier committed observation. That is a substantive requirement choice. It must be attached to the actual consuming read path; the supplier's ability to provide default linearizable reads elsewhere does not establish that this consumer uses them.
Freshness also affects the meaning of availability. A successful default current read carries its ordering obligation. When the service cannot satisfy that obligation, waiting or failing is different from successfully returning an older value. The guarantee constrains a successful result; it does not promise a response within a deadline.
If a proposal describes continued member-local responses during a disruption affecting consensus, those responses need to be assessed under their offered semantics. Their existence alone establishes neither continued current linearizable reads nor continued agreement on new writes. A response counter can hide the very distinction the buyer needs to resolve.
An ordered watch is not a current-state freshness promise
The etcd v3.6 Watch API delivers change notifications ordered by revision. The API guarantees explicitly exclude linearizability for watches, and delivery has no guaranteed finite delay.
Imagine an observer whose last received event describes A. The B write then completes, but the observer has not received its event. That observation is compatible with delayed notification; it does not disprove the completed write. Waiting for a stream to appear quiet supplies no proof that the observer has reached the current state.
A watch event identifying B establishes an update in the stream's ordered history. Outside QR-224's no-later-mutation premise, it cannot by itself establish that nothing has superseded B by the time the application acts.
Watches can therefore inform an application about changes without becoming reads with a bounded freshness interval. The software provider needs to explain the consumer's actual observation contract if the offer relies on watch-fed state.
References: [ER1]
Compare the read requirement before ranking the replica counts
Consider two hypothetical offers for the same small coordination workload. Offer M has five stipulated voting members and supplies the consumer's current lookups through serializable member-local reads. Offer R has three stipulated voting members and supplies those lookups through default linearizable reads. Assume the offered behavior is supported as described.
Offer M has the larger simplified member-failure allowance: two instead of one. It still permits QR-224's stale A result. For a buyer whose requirement forbids that result after the B acknowledgement, its extra voters do not close the read-contract gap.
Offer R supplies the relevant successful-read ordering, while its three voters provide only the one-failure allowance calculated earlier. A buyer requiring both the B freshness result and tolerance of two member failures has not found both in either stated offer. This comparison establishes no preferred deployment; it identifies why the two proposal labels cannot be ranked on one scale.
Make the proposed service explain the result the application needs. The useful evidence connects the stipulated voting membership and failure assumptions to the read mode actually used by this consumer, including what happens when a qualifying result cannot be obtained. Any response deadline or service-level promise requires additional evidence beyond the quorum arithmetic.
That explanation resolves a purchasing ambiguity which more copies alone cannot resolve: agreement on coordination state, the freshness of one observation and timely service to the application are related requirements with distinct evidence.
Bring approved physical connections into the cabling scope
If the selected system also requires physical IT connections, Leviathan's Structured Cabling & Fiber Installation service and its project inquiry provide a route to discuss agreed cable installation, labels and connection records.
Share a nonconfidential equipment and site summary, approved endpoints and routes, the appointed materials supplier and the requested physical handoff. Coordination-service design, administration and client read policy remain with the appointed software provider. This educational comparison supplies no deployment procedure or work authorization.
References: [L1]
Primary sources
- [EQ1] etcd v3.6 FAQ: coordination service, voting majority and failure toleranceChecked 2026-10-20. The small coordination-data description and majority/failure-tolerance discussion support the fixed-voter arithmetic. Member counts do not establish failure-domain independence or a service-level guarantee.
- [ER1] etcd v3.6 API guarantees: linearizability, watches and operation completionChecked 2026-10-20. Defines real-time ordering and acknowledged completion, distinguishes the optional serializable read mode, and states that watches lack linearizability and a finite delivery bound. Applies to the named API guarantees rather than every replicated database.
- [ER2] etcd v3.6 API: Range request semanticsChecked 2026-10-20. Distinguishes current and historical revisions, default linearizable Range behavior and optional serializable member-local reads. Useful for matching the consumer's read contract to its freshness requirement.
- [L1] Leviathan Systems: Structured Cabling & Fiber InstallationChecked 2026-10-20. Describes agreed physical IT cabling, labels and connection records. Useful when a wider equipment project requires physical connections with separately assigned software responsibilities.