Architecture: consistency and evolution · 3 MIN READ
Consistency under partitions: explain an operation, not a slogan
Choose per-operation consistency and failure behavior instead of treating CAP as a product rating.
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.
system-design · A MAP OF THE IDEA
- Define operation guarantee
- Identify authoritative state
- Handle lost coordination
- Reconcile and fault-test
Useful when
- Choose per-operation consistency and failure behavior instead of treating CAP as a product rating.
- Makes the owner and the failure boundary explicit.
Watch out
- Do not claim that a system simply chooses any two of consistency, availability and partition tolerance.
- Run native service and failure tests in your own development environment.
Implementation & operation cost: Additional state and tests must be justified by the demonstrated failure; this lesson is not a requirement for every Go program.
The contract and the failure
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.
Work through the example
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.
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.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.
Production decisions
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.
Explain it in an interview
Does a majority-count helper by itself implement linearizable distributed storage? No. A consistency protocol also needs durable ordering, authority and membership rules; define the guarantee and failure policy of each operation. Describe the state before the operation, its owner, the failure between steps and the evidence you would test. Distinguish what this example demonstrates from the infrastructure a production service still needs.
TAKE THIS WITH YOU
Choose per-operation consistency and failure behavior instead of treating CAP as a product rating. No. A consistency protocol also needs durable ordering, authority and membership rules; define the guarantee and failure policy of each operation.
Check your understanding
Does a majority-count helper by itself implement linearizable distributed storage?
Go to the source
Progress stays in this browser. No account needed.