Key Consistency Models

Why This Matters

Consistency models define the rules for how distributed systems maintain reliable data across multiple nodes, processes, and geographic regions. They govern the tradeoffs between data accuracy, system availability, and performance. These models show up constantly in questions about distributed databases, cloud computing architectures, and concurrent programming.

Don't just memorize definitions. Know what problem each model solves and what tradeoffs it accepts. You'll be asked to recommend consistency models for specific scenarios, compare the ordering guarantees of different models, or explain why a system like DNS uses eventual consistency while a banking system requires something stronger. Master the why behind each model, and the scenario questions become straightforward.

---

Strong Ordering Guarantees

These models provide the strictest guarantees about how operations appear across the system. They sacrifice performance for correctness, requiring coordination mechanisms that introduce latency but ensure all processes see the same global state.

Strong Consistency

• All operations appear instantaneous. Every read reflects the most recent write, with no ambiguity about ordering across the entire system.
• Write acknowledgment guarantees visibility. Once a write completes, every subsequent read from any process will see that value.
• Synchronization overhead is significant. Requires coordination protocols like two-phase commit or consensus algorithms (e.g., Paxos, Raft), making it costly in geographically distributed systems.

Linearizability

• Real-time ordering preserved. Each operation appears to take effect at a single point between its invocation and its response, respecting wall-clock time.
• Single global timeline. All processes agree on one consistent ordering that matches the actual temporal sequence of operations.
• Gold standard for correctness-critical systems. Used in distributed coordination services (e.g., ZooKeeper, etcd) where correctness cannot be compromised.

Note that linearizability is sometimes treated as the formal definition of strong consistency. The distinction matters: "strong consistency" is often used informally to mean "reads always see the latest write," while linearizability is a precisely defined property with real-time constraints. In practice, many systems that claim "strong consistency" are actually providing linearizability.

Sequential Consistency

• Global sequential order exists. All processes see operations in the same total order, though this order doesn't need to match real-time.
• Program order respected. Each process's operations appear in the sequence that process issued them.
• More relaxed than linearizability. Two operations that don't overlap could appear in a different order than their wall-clock timing suggests, as long as every process agrees on the same order.

---

Relaxed Global Ordering

These models relax the requirement that all processes see the same global order. They permit different views across processes while maintaining specific guarantees, enabling better performance in distributed environments.

Causal Consistency

• Causally related operations maintain order. If operation A could have influenced operation B (e.g., B read a value written by A, or A happened before B in the same process), all processes see A before B.
• Concurrent operations may vary. Operations with no causal relationship can appear in different orders to different processes.
• Captures logical dependencies. Uses Lamport's happens-before relation to determine what must be ordered. Two operations are concurrent if neither causally depends on the other.

PRAM (Pipelined RAM) Consistency

• Per-process ordering guaranteed. Writes from a single process are seen in order by all other processes.
• Cross-process writes unordered. Writes from different processes may appear in different orders to different observers.
• Also called FIFO consistency. The name reflects that each process's writes flow through a pipeline (FIFO queue) to other processes, preserving their issue order.

---

Client-Centric Guarantees

These models focus on what an individual client or session experiences rather than global system state. They're designed for user-facing applications where perceived consistency matters more than absolute global ordering. Systems often layer these guarantees on top of a weaker base model like eventual consistency.

Read-Your-Writes Consistency

• Own writes always visible. A process is guaranteed to see any write it has previously performed.
• Other processes may lag. No guarantee that other clients see your writes immediately.
• Essential for user experience. Prevents the frustrating scenario where you update your profile but the page still shows the old version.

Session Consistency

• Consistent view within a session. All operations within a user's session see a coherent, progressively updated state.
• Cross-session views may differ. Different users or sessions can see different snapshots of the data.
• Practical implementation detail: Session consistency is often achieved by pinning a client to a specific replica for the duration of a session, or by tracking a session token that encodes the last-seen version.

Monotonic Read Consistency

• No going backward. Once a process reads a value, subsequent reads return that value or something newer.
• Prevents stale data regression. Eliminates scenarios where refreshing a page shows older information than what you just saw.
• Common violation scenario: A client's requests get routed to different replicas via a load balancer, and one replica is behind. Without monotonic reads, you could see a newer value then suddenly see an older one.

Monotonic Write Consistency

• Write order preserved per process. A process's writes are applied at every replica in the order they were issued.
• Prevents write reordering. Ensures a later write isn't applied before an earlier one from the same source.
• Maintains logical update sequences. Critical for applications where operation order carries semantic meaning (e.g., "create account" must be applied before "update account settings").

---

Availability-Optimized Models

When system availability and partition tolerance matter more than immediate consistency, these models accept temporary inconsistencies in exchange for better performance and fault tolerance.

Eventual Consistency

• Convergence guaranteed, timing isn't. If updates stop, all replicas will eventually reach the same state, but there's no bound on how long this takes.
• Temporary inconsistencies accepted. Different nodes may return different values for the same data during the convergence window.
• Powers high-availability systems. Used in DNS, social media feeds, and NoSQL databases (e.g., DynamoDB, Cassandra in default mode) where availability trumps immediate accuracy.
• Conflict resolution required. When concurrent writes happen at different replicas, the system needs a strategy to resolve conflicts (last-writer-wins, vector clocks, CRDTs, application-level merging).

---

Quick Reference Table

---

Self-Check Questions

1. Which two consistency models both guarantee a global ordering of operations, and what distinguishes them from each other?

2. A user posts a comment on a social media platform but doesn't see it appear when they refresh. Which client-centric consistency guarantee has been violated?

3. Compare and contrast Causal Consistency and PRAM Consistency. Under what circumstances would PRAM allow different orderings that Causal Consistency would not?

4. You're designing a distributed banking system that processes transfers between accounts. Which consistency model would you recommend, and why would eventual consistency be inappropriate?

5. Explain how Monotonic Read Consistency and Monotonic Write Consistency could both be satisfied in a system that doesn't provide Sequential Consistency. What global guarantee would still be missing?