We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Consistency Models
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Consistency Models
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
When someone says their database is "consistent," the follow-up question should always be: what kind of consistent? There are at least a dozen meanings, each with vastly different performance characteristics and failure modes.
At one end: eventual consistency, where reads might return stale data, but replicas converge over time. At the other end: linearizability, where every read returns the most recent write, as if a single copy existed. Between them: monotonic reads, read-your-writes, causal, sequential, snapshot isolation, and serializability.
This lesson maps the entire spectrum. It explains why DynamoDB feels different from Spanner, why Cassandra with differs from ONE, and why your cache sometimes shows data from five minutes ago. Every model makes a specific trade-off between safety and performance. Picking the wrong one costs either money (over-provisioned coordination) or correctness (data loss and confused users).
| Model | Guarantee | Cost | Example System |
|---|---|---|---|
| Eventual | Replicas converge eventually | Lowest | DynamoDB (default), Cassandra (CL=ONE) |
| Monotonic reads | Never see older values after newer ones | Session routing | Most databases with sticky sessions |
| Read-your-writes | See your own writes immediately | Route to primary after write | Firebase, many web apps |
| Causal | Causally related ops seen in order | Vector clock metadata | COPS, some Cassandra configs |
| Sequential | Single global order for all ops | Coordination overhead | ZooKeeper reads |
| Snapshot isolation | Transaction sees point-in-time snapshot | MVCC versioning overhead | PostgreSQL, CockroachDB |
| Serializability | As if transactions ran serially | Locking or SSI overhead | PostgreSQL SERIALIZABLE |
| Linearizability | Real-time ordering of all ops | protocol | etcd, Spanner, ZooKeeper writes |
Moving down this table, guarantees get stronger but costs increase. The engineering challenge is choosing the weakest model that satisfies your requirements. Overshoot and you pay in latency. Undershoot and you pay in bug reports.