Consistency Models, From Strong to Eventual — Cheatsheet

The models, strongest first

Linearizable (strong)	Every read sees the latest committed write; behaves like one copy.Cost: cross-replica coordination → latency, and unavailability under partition.
Sequential	All clients see operations in one consistent order — not necessarily real time.
Causal	Causally-related operations are seen in order; concurrent ones may differ.The usual sweet spot for collaborative apps.
Read-your-writes	You always see your own writes, even if others lag.
Monotonic reads	Once you’ve seen a value, you never see an older one.
Eventual	Replicas converge if writes stop; no ordering guarantee meanwhile.Cheapest, most available; fine for like-counts, not balances.

CAP	Under a network partition, choose Consistency or Availability — you can’t keep both.
PACELC	Else (no partition), you still trade Latency vs Consistency.
Quorum (R + W > N)	Guarantees a read overlaps the latest write across N replicas.

Attach the model to the data, not the system: balances need read-your-writes or stronger; a feed tolerates eventual. Say which per entity.
“Strong consistency” is not free — name the cost you’re accepting: higher write latency and reduced availability when a replica is unreachable.
Quorums (R + W > N) are how you tune the knob between the two without going fully strong or fully eventual.