Class 2 Post-Class
Consistency Models Deep Dive + 30-Question Quiz

In Class 2, we learned about the CAP theorem: in a distributed system, you must choose between Consistency and Availability during a network partition. But that raises a crucial follow-up question: what exactly do we mean by "consistency"? It turns out there is not just one kind — there is an entire spectrum, from the strictest guarantees to the loosest.

Understanding this spectrum is essential because different parts of your system need different consistency levels. A payment system that allows a user to spend money they have already spent would be catastrophic. But a social media feed that shows a post 2 seconds late? Nobody notices. Choosing the right consistency model for each feature is one of the most important architectural decisions you will make.

Moving from left to right on this spectrum, you trade correctness for performance. Stronger models require more coordination between nodes (adding latency and reducing availability), while weaker models allow nodes to respond independently (faster and more available but may return stale data).

Linearizability is the gold standard of consistency. It provides the illusion that there is only one copy of the data in the entire system, and every operation is atomic — it happens instantaneously at some point between its start and completion. After a write completes, every subsequent read from any node in the system is guaranteed to return the new value.

How it works: A leader node coordinates all writes. Before a write is acknowledged, the leader ensures a majority of replicas (quorum) have accepted it. Consensus protocols like Raft and Paxos implement this.

The cost: Every write requires a round-trip to a majority of nodes. This adds latency (50–200ms for cross-region writes) and reduces availability (if a majority of nodes are unreachable, the system halts).

Sequential consistency is slightly weaker than linearizability. It guarantees that all clients see all operations in the same order, and operations from each individual client appear in the order that client issued them. However, it does not guarantee real-time ordering — a write at time T may not be visible to other clients until some later time.

The critical rule: If Client 1 writes x=1 and then writes y=2, every other client must see x=1 before y=2. They can see both late, but the order must be preserved.

How it differs from linearizability: With linearizability, a write at 10:00:00 must be visible to readers at 10:00:01. With sequential consistency, the write may still be invisible at 10:00:01 — it only guarantees the order of operations is consistent, not that it matches real time.

Causal consistency relaxes the ordering guarantee further. Instead of requiring all operations to be ordered, it only requires causally related operations to be ordered. Two operations are causally related if one could have influenced the other. Concurrent, independent operations can appear in any order.

The intuition: If Alice says "Anyone free?" and Bob replies "I am!", everyone must see Alice's message before Bob's reply — the reply was caused by the question. But Dave's unrelated message "Nice weather!" can appear in any order — it was not caused by either.

How it is tracked: Vector clocks or version vectors track causal dependencies. Each operation carries metadata about which operations it "depends on."

Session guarantees are a pragmatic middle ground that makes eventual consistency much more usable. Instead of guaranteeing consistency across all clients, they guarantee consistency within a single client's session. This is often sufficient — the most jarring inconsistency for users is when they perform an action and cannot see their own change.

• Read Your Writes (RYW): After you write a value, your subsequent reads will always return at least that value. You will never upload a profile picture and then refresh to see the old one. The most important session guarantee.
• Monotonic Reads: Reads never "go backwards in time." If you read value V at time T1, reading again at T2 will return V or something newer — never something older.
• Monotonic Writes: Your writes are applied in the order you issued them. Updating name to "Alice" then "Alice Smith" is always applied in that order.
• Writes Follow Reads: If you read a value and then write based on it, your write is guaranteed to be applied after the read. Post a reply only after the thread exists.

Eventual consistency is the weakest useful guarantee. It promises only that if no new updates are made, eventually all replicas will converge to the same value. During the convergence window, different nodes may return different values for the same data.

The convergence window: In Cassandra with healthy networks, typically under 100ms. In a geo-replicated DynamoDB with global tables, can be 1–2 seconds. In DNS, the TTL can mean hours of staleness.

Conflict resolution strategies: Last-Write-Wins (LWW) uses timestamps; CRDTs (Conflict-free Replicated Data Types) allow automatic conflict-free merging; Application-level resolution presents both values to the user.

Modern databases like Cassandra and DynamoDB offer tunable consistency — you choose the consistency level per query. The magic formula: if W + R > N (where W = write quorum, R = read quorum, N = replication factor), you get strong consistency.

With N=3: QUORUM writes (W=2) + QUORUM reads (R=2) = 4 > 3, so you always read the latest write. ONE/ONE = 1+1=2, which is NOT > 3, so you may read stale data — but it is much faster and more available.