Replication and Consistency Models
Replication keeps multiple copies of data for availability, read scaling, and latency. The hard part is what happens when copies disagree. A consistency model is the contract for what reads may observe given concurrent writes, and it is fundamentally constrained by network partitions.
Three replication topologies dominate: single-leader (writes go to one leader, replicate to followers — simple, the default for relational DBs), multi-leader (several leaders accept writes, replicate to each other — better for multi-region writes, but needs conflict resolution), and leaderless (any replica takes writes; quorum reads/writes reconcile — Dynamo-style). Source: Kleppmann, Designing Data-Intensive Applications
CAP and PACELC
CAP: when a network Partition happens, a system must choose Consistency (reject/stall to stay correct) or Availability (serve possibly-stale data). You cannot have both during a partition. Source: Brewer, CAP
PACELC completes the picture: if Partition → choose A or C; Else (normal operation) → choose Latency or Consistency. Even with no partition, stronger consistency costs latency (more replicas to coordinate). This is the more useful daily framing. Source: Abadi, PACELC
Quorums
With N replicas, require W acknowledgments per write and R replicas per read. If W + R > N, read and write sets overlap, so a read sees the latest write — tunable consistency. Raising W/R strengthens consistency at the cost of availability and latency; lowering them does the reverse. Leaderless stores expose W/R/N directly. Source: Kleppmann, DDIA
A ladder of guarantees
| Model | Guarantee |
|---|---|
| Linearizable | One global order; a read sees the most recent write (as if one copy) |
| Sequential / causal | Operations respect causal/program order, not necessarily real time |
| Read-your-writes | A client always sees its own prior writes |
| Eventual | Replicas converge if writes stop; reads may be stale meanwhile |
Stronger is easier to reason about but slower and less available; weaker is fast and available but pushes anomaly-handling into the application.
Design implications
- Linearizability is expensive. It needs consensus (Consensus Protocols (Raft and Paxos)) or synchronous quorums; reserve it for data that truly needs it (locks, balances).
- Most systems are eventually consistent and add targeted guarantees (read-your-writes) where users would notice.
- Conflicts are inevitable in multi-leader/leaderless. Resolve with last-write-wins (lossy), version vectors, or CRDTs.
- Replication lag breaks read-after-write on followers; route those reads to the leader or use a session guarantee.
The append-only log of Event Sourcing and CQRS makes eventual consistency tractable (replay converges), and the freshness/staleness knobs here are exactly what Distributed Caching Architecture trades on.
Architecture Position
| Axis | Value |
|---|---|
| Family | Distributed systems primitives |
| Boundary owned | Data copies, consistency tradeoffs, leader/follower, quorum, and conflict behavior. |
| Read with | Consensus Protocols (Raft and Paxos), Sharding and Partitioning Architecture, Distributed Caching Architecture |
| Use this page when | choosing data consistency and availability tradeoffs |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Distributed systems primitives family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Data copies, consistency tradeoffs, leader/follower, quorum, and conflict behavior. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured single/multi/leaderless replication, CAP, the PACELC refinement, W+R>N quorums, the linearizable→eventual ladder, and conflict-resolution + lag implications. Source: compiled from Brewer (CAP), Abadi (PACELC), Kleppmann (DDIA)