Consistency Models
Strong (Linearizable)
Every read returns the most recent write. As if there's one copy. Highest correctness, highest latency. Examples: Spanner, CockroachDB, Zookeeper.
Sequential Consistency
All operations appear in some total order consistent with each process's local order. Weaker than linearizable — doesn't respect real-time ordering.
Causal Consistency
If A causally precedes B, everyone sees A before B. Concurrent (unrelated) operations may be seen in different orders. Used in MongoDB (causal sessions).
Read-Your-Writes
A client always sees its own writes. Others may see stale data. Implemented via sticky sessions or version vectors. Common in social media feeds.
Monotonic Reads
Once a client reads value V, it never sees an older value. No 'going back in time'. Often combined with read-your-writes for good UX.
Eventual Consistency
If no new writes occur, all replicas eventually converge to the same value. Weakest guarantee, highest availability. Examples: DNS, Cassandra (ONE), S3.
Strong Eventual Consistency
Eventual consistency + conflict-free. Uses CRDTs (Conflict-free Replicated Data Types). No conflicts to resolve, guaranteed convergence. Examples: Riak, Automerge.
Tunable Consistency
Systems like Cassandra let you choose per-query. ONE (fast, eventual), QUORUM (balanced), ALL (strong, slow). Trade latency for correctness per operation.
Consistency vs Latency
Strong consistency requires coordination (consensus rounds, 2PC) → higher latency. Eventual consistency needs no coordination → lower latency. PACELC captures this.
Real-World Defaults
DynamoDB: eventual (default), strong (optional). PostgreSQL: strong (single node). Cassandra: tunable. MongoDB: strong (single doc), eventual (replica reads).