upgrade
upgrade

💻Parallel and Distributed Computing

Key Consistency Models

Study smarter with Fiveable

Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.

Get Started

Why This Matters

Consistency models are the backbone of how distributed systems maintain reliable data across multiple nodes, processes, and geographic regions. When you're studying parallel and distributed computing, you're being tested on your ability to understand the tradeoffs between data accuracy, system availability, and performance. These models appear constantly in exam questions about distributed databases, cloud computing architectures, and concurrent programming—and understanding them means knowing when to sacrifice strict guarantees for speed, or when absolute correctness is non-negotiable.

Don't just memorize definitions—know what problem each model solves and what tradeoffs it accepts. Exam questions will ask you 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 you'll be ready for anything.


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 can 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, making it costly in geographically distributed systems

Linearizability

  • Real-time ordering preserved—operations appear to take effect at a single point between their invocation and 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 critical systems—used in distributed databases and coordination services where correctness cannot be compromised

Sequential Consistency

  • Global sequential order exists—all processes see operations in the same 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—doesn't require real-time correspondence, allowing more implementation flexibility

Compare: Linearizability vs. Sequential Consistency—both guarantee a global ordering, but linearizability requires operations to respect real-time ordering while sequential consistency only requires a consistent sequence. If an FRQ asks about "strongest consistency guarantees," linearizability is your answer.


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, 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 happens-before relationships to determine what must be ordered

PRAM (Pipelined Random Access Memory) 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
  • Efficient for parallel memory access—allows pipelining of operations while maintaining minimal ordering constraints

Compare: Causal Consistency vs. PRAM—both allow different processes to see different orderings, but causal consistency tracks logical dependencies across processes while PRAM only guarantees ordering within a single process's writes. Causal is strictly stronger.


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.

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 a user updates their profile but doesn't see the change

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
  • Balances UX with scalability—provides intuitive behavior for individual users without global coordination costs

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
  • Progressive updates guaranteed—users see data that only moves forward in time, never backward

Monotonic Write Consistency

  • Write order preserved per process—a process's writes are applied in the order they were issued
  • Prevents write reordering—ensures a later write isn't visible before an earlier one from the same source
  • Maintains logical update sequences—critical for applications where operation order carries semantic meaning

Compare: Monotonic Read vs. Monotonic Write—both provide "monotonic" guarantees but in opposite directions. Monotonic read ensures you never see older data after seeing newer data; monotonic write ensures your writes are applied in order. An FRQ might ask you to identify which guarantee a shopping cart system needs (hint: both).


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
  • Temporary inconsistencies accepted—different nodes may return different values for the same data during updates
  • Powers high-availability systems—used in DNS, social media feeds, and NoSQL databases where availability trumps immediate accuracy

Compare: Strong Consistency vs. Eventual Consistency—these represent opposite ends of the consistency spectrum. Strong consistency guarantees immediate visibility but requires coordination; eventual consistency maximizes availability but accepts temporary divergence. The CAP theorem forces distributed systems to choose between them during network partitions.


Quick Reference Table

ConceptBest Examples
Strictest global orderingLinearizability, Strong Consistency
Global order without real-timeSequential Consistency
Partial ordering by causalityCausal Consistency, PRAM
Per-client guaranteesRead-Your-Writes, Session Consistency
Monotonic progressMonotonic Read, Monotonic Write
Maximum availabilityEventual Consistency
Banking/financial systemsLinearizability, Strong Consistency
Social media/DNSEventual Consistency

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?