Staff / expert · Architecture and systems
A quorum slogan is proposed as a correctness proof
A service counts three acknowledgements from five replicas and claims every read/write is linearizable. What is absent from that argument?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
package main
import "fmt"
func majority(replicas, acks int) bool {
return replicas > 0 && acks >= replicas/2+1 && acks <= replicas
}
func main() { fmt.Println(majority(5, 2), majority(5, 3)) }
// Threshold arithmetic only: this is not a consensus or replication algorithm.Reveal a strong answer
A network partition can prevent replicas from coordinating. Whether a particular operation may proceed depends on the required consistency contract and the available authority, not on whether the service was written in Go or has a cache. Specify which reads may be stale, which writes require a leader or quorum, and what the caller sees when that requirement cannot be met.
State requirements per use case: a cached catalog may tolerate lag, while spending a balance or reserving an account nonce may require serialized authority. Define read-your-writes behavior, version checks and reconciliation for replicas or projections. Distinguish the availability/consistency tradeoff during a partition from ordinary latency and throughput tradeoffs even when the network is healthy. Three acknowledgements meet a simple majority threshold for five configured replicas; two do not. The predicate demonstrates arithmetic only. Real consensus also needs terms, log ordering, membership changes, persistence and safety rules. Counting arbitrary replies does not prove a linearizable write or that a stale leader cannot act.
Do not claim that a system simply chooses any two of consistency, availability and partition tolerance. A timestamp or a mutex in each replica does not establish a global order. A quorum slogan does not replace a protocol or fault test. Demonstrate split connectivity, stale leadership, concurrent writes, membership changes and recovery, then explain the exact guarantee your operation can still make.
Common trap
Counting arbitrary replies or naming a system CP/AP does not prove the required business consistency.
Try it
Specify leader/term authority, persistence, ordering, membership and recovery for an operation; contrast a stale catalog read with a balance spend.
Worked solution
A majority predicate is arithmetic, not a consensus algorithm or storage contract. The protocol must establish durable ordering, valid authority, membership rules and the exact read guarantee. During a partition, decide which operations refuse service and which may use stale or independently accepted state under a reconciliation policy. CAP is not a free choice of any two product labels, and local mutexes or timestamps do not create a global order.
Change the constraint
How do read-your-writes, stale leaders and membership changes affect the operation’s guarantee?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-28. Use documentation for your pinned runtime, driver and tool version.