← Back to Overview

🔄 Complete Guide to Consistency Models

Master distributed system consistency with detailed explanations and simple analogies

Table of Contents

Introduction

Consistency models define the rules about when and how updates to a distributed system become visible to different parts of the system. Think of consistency models as "rules of engagement" for how multiple processes can interact with shared data in a distributed system.

Simple Analogy: Imagine a shared whiteboard in a classroom where multiple students can write. Consistency models are like different sets of rules:
  • Strong rules: Only one student can write at a time, everyone sees changes immediately
  • Weak rules: Multiple students can write simultaneously, but there might be delays in seeing each other's changes

Fundamental Concepts

Systems and State

A distributed system has a logical state that changes over time. For example:

Processes

A process is a single-threaded program that performs operations. Think of it as one person using the system at a time.

Operations

An operation changes the system from one state to another:

Concurrency and Time

Operations have:

Analogy: Like phone calls - you dial (invoke), talk (execute), and hang up (complete). Two calls are concurrent if they overlap in time.

Consistency Model Hierarchy

graph TD SS[Strict Serializable
🔒 Strongest] --> S[Serializable
📋 Transaction Order] SS --> L[Linearizable
⏰ Real-time Order] S --> RR[Repeatable Read
📖 Same Read Results] S --> SI[Snapshot Isolation
📸 Consistent Snapshots] RR --> CS[Cursor Stability
🔍 Stable Cursors] SI --> MAV[Monotonic Atomic View
📊 Atomic Views] CS --> RC[Read Committed
✅ Only Committed Data] MAV --> RC RC --> RU[Read Uncommitted
⚠️ Dirty Reads Allowed] L --> SEQ[Sequential Consistency
🔄 Global Order] SEQ --> CAUSAL[Causal Consistency
🔗 Cause-Effect Order] CAUSAL --> WFR[Writes Follow Reads
📝 Read-then-Write] CAUSAL --> PRAM[PRAM Consistency
🚰 Per-Process Order] PRAM --> MR[Monotonic Reads
📈 Never Go Backward] PRAM --> MW[Monotonic Writes
📤 Write Order Preserved] PRAM --> RYW[Read Your Writes
👁️ See Own Changes] MR --> EC[Eventual Consistency
🕐 Eventually Consistent] MW --> EC RYW --> EC WFR --> RYW %% Styling classDef strongest fill:#ff6b6b,stroke:#d63031,stroke-width:3px,color:#fff classDef strong fill:#fd79a8,stroke:#e84393,stroke-width:2px,color:#fff classDef medium fill:#fdcb6e,stroke:#e17055,stroke-width:2px,color:#000 classDef weak fill:#6c5ce7,stroke:#5f3dc4,stroke-width:2px,color:#fff classDef weakest fill:#74b9ff,stroke:#0984e3,stroke-width:2px,color:#fff class SS strongest class S,L strong class RR,SI,SEQ,CAUSAL medium class CS,MAV,RC,WFR,PRAM weak class MR,MW,RYW,RU,EC weakest

Strong Consistency Models

1Strict Serializable

📋Definition

The strongest consistency model that combines serializability (for transactions) with linearizability (for real-time ordering).

💡Simple Analogy

Like a high-security bank vault where:

  • Complex transactions (moving money between accounts) happen atomically
  • Everything happens in real-time order
  • No two operations can interfere with each other

⚙️Key Properties

  • Transactions appear to execute in some serial order
  • Real-time ordering is preserved
  • Strongest possible guarantee
  • Not available in asynchronous networks

💻Example

In a banking transfer scenario where $100 is moved from Account A to Account B, strict serializable consistency ensures that any concurrent read operation sees either the complete before-state or the complete after-state, never a partial state that would violate the transfer invariant.

2Linearizable (Atomic Consistency)

📋Definition

Every operation appears to take effect atomically at some point between its start and completion, respecting real-time ordering.

💡Simple Analogy

A single-window bank teller serving customers one at a time. No matter how many people are in line, each transaction happens completely before the next one starts, and everyone sees the same account balance.

⚙️Key Properties

  • Operations appear instantaneous
  • Real-time ordering preserved
  • All processes see the same order
  • Applies to single objects

💻Example

If Process A writes a value and completes before Process B starts reading, linearizable consistency guarantees that Process B must see the value written by Process A, maintaining real-time ordering.

3Sequential Consistency

📋Definition

All operations appear to execute in some sequential order, and each process sees operations in the same order, but real-time ordering is not required.

💡Simple Analogy

Like a group chat where everyone receives messages in the same order, but the order might not match exactly when messages were sent due to network delays.

⚙️Key Properties

  • Global ordering exists
  • All processes see same order
  • Real-time ordering not required
  • Weaker than linearizability

💻Example

In sequential consistency, if Process A writes x=1 and then Process B writes x=2, all nodes might see either order (x=1 then x=2, or x=2 then x=1) as long as all nodes see the same order. Real-time ordering is not required.

Transaction-Based Models

4. Serializable

Definition: Transactions appear to execute in some serial order, but real-time ordering is not required.
Simple Analogy: Like a restaurant kitchen where complex orders are prepared, but they might be completed in a different order than they were received, as long as each complete meal is served properly.
Key Properties:
  • Transactions appear atomic
  • Some serial execution order exists
  • No real-time constraints
  • Prevents anomalies like dirty reads, phantom reads

5. Snapshot Isolation

Definition: Each transaction sees a consistent snapshot of the database as of the time it started.
Simple Analogy: Like taking a photograph of a busy street. Your photo shows a consistent moment in time, even though the street continues to change while you're looking at the photo.
Key Properties:
  • Transactions see consistent snapshots
  • No dirty reads or non-repeatable reads
  • Write-write conflicts are prevented
  • May allow write skew anomalies
Example:

Two transactions T1 and T2 start simultaneously and see the same snapshot of accounts A and B. T1 updates account A while T2 updates account B. Both transactions can commit successfully since they don't conflict, resulting in both updates being applied to the final state.

6. Repeatable Read

Definition: Within a transaction, reading the same data multiple times returns the same result.
Simple Analogy: Like reading a book where the pages don't change while you're reading it, even if someone else might be editing other copies of the book.
Key Properties:
  • No dirty reads
  • No non-repeatable reads
  • May allow phantom reads
  • Weaker than serializable

7. Read Committed

Definition: Transactions only see data that has been committed by other transactions.
Simple Analogy: Like only reading published articles in a newspaper, never seeing the rough drafts that reporters are still working on.
Key Properties:
  • No dirty reads
  • Allows non-repeatable reads
  • Allows phantom reads
  • Most common isolation level

8. Read Uncommitted

Definition: Transactions can see uncommitted changes from other transactions.
Simple Analogy: Like being able to peek at someone's rough draft while they're still writing it - you might see changes that get erased later.
Key Properties:
  • Allows dirty reads
  • Weakest transaction isolation
  • Highest performance, lowest consistency

Single-Object Models

9. Causal Consistency

Definition: Operations that are causally related must be seen in the same order by all processes, but concurrent operations can be seen in different orders.
Simple Analogy: Like a conversation thread on social media. Everyone must see replies after the original post they're responding to, but if two people comment simultaneously, different users might see those comments in different orders.
Key Properties:
  • Preserves cause-and-effect relationships
  • Concurrent operations can be reordered
  • Respects "happens-before" relationships
  • Weaker than sequential consistency
Example:

If Process A writes to x and then writes to y (causally related operations), all nodes must see x's update before y's update. However, if Process B concurrently writes to z, that operation can appear at any point in the sequence since it's not causally related to A's operations.

10. PRAM Consistency (Pipeline RAM)

Definition: Each process sees its own operations in the order it issued them, but operations from different processes can be seen in any order.
Simple Analogy: Like personal diaries that get shared. You always write in your diary in chronological order, and when others read your diary, they see your entries in sequence. But when multiple diaries are combined, entries from different people can be mixed in any order.
Key Properties:
  • Per-process ordering preserved
  • No global ordering requirement
  • Operations from different processes can be arbitrarily interleaved
Example:

Process A performs a sequence of writes to variable x, while Process B writes to variable y. PRAM consistency ensures that all nodes see A's writes in the order A issued them, and B's writes in the order B issued them. However, the interleaving of A's and B's operations can vary across different nodes.

Session Guarantees

11. Monotonic Reads

Definition: If a process reads a value, any subsequent reads by that process will return the same value or a more recent value.
Simple Analogy: Like reading a book - once you've read up to page 50, you'll never accidentally flip back and read page 30 thinking it's new content. You can only move forward or stay at the same page.
Example:

If a process reads x=5 at time T1, then later reads at T2, T3, T4 will return x=5, x=7, x=7 (never a smaller value like x=3). The process can only see the same value or newer values, never going backwards.

12. Monotonic Writes

Definition: Writes by a single process are seen by all processes in the order they were issued.
Simple Analogy: Like sending numbered letters to friends. Even if the postal system is unreliable, your friends will receive letter #1 before letter #2, and letter #2 before letter #3.

13. Read Your Writes

Definition: A process always sees the effects of its own previous writes.
Simple Analogy: Like writing a note and being able to read what you just wrote. You never experience amnesia about your own actions.
Example:

If a process writes x=10, then immediately reads x, it must return 10 (or a newer value if another process has updated it). The process never experiences amnesia about its own writes.

14. Writes Follow Reads

Definition: If a process reads a value and then writes, the write is guaranteed to take place on a copy that is at least as recent as the one where the read took place.
Simple Analogy: Like editing a document - if you read version 5 of a document and then make changes, your changes are applied to version 5 or later, never to an older version.

Model Relationships and Implications

Implication Chain

When we say model A "implies" model B, it means every history that satisfies A also satisfies B. A is "stronger" than B.

graph TD SS[Strict Serializable
🔒 Strongest] SS --> S[Serializable
📋 ACID Transactions] SS --> L[Linearizable
⏰ Real-time Atomic] S --> RR[Repeatable Read
📖 No Non-repeatable Reads] S --> SI[Snapshot Isolation
📸 MVCC Databases] RR --> CS[Cursor Stability
🔍 Stable Read Cursors] SI --> MAV[Monotonic Atomic View
📊 Atomic Snapshots] CS --> RC[Read Committed
✅ No Dirty Reads] MAV --> RC RC --> RU[Read Uncommitted
⚠️ Allows Dirty Reads] L --> SEQ[Sequential Consistency
🔄 Total Order] SEQ --> CAUSAL[Causal Consistency
🔗 Happens-Before] CAUSAL --> PRAM[PRAM Consistency
🚰 Per-Process Order] CAUSAL --> WFR[Writes Follow Reads
📝 Read-Write Dependencies] PRAM --> MR[Monotonic Reads
📈 Forward Progress Only] PRAM --> MW[Monotonic Writes
📤 Write Order Preserved] PRAM --> RYW[Read Your Writes
👁️ Session Consistency] WFR --> RYW MR --> EC[Eventual Consistency
🕐 Convergence Guarantee] MW --> EC RYW --> EC classDef strongest fill:#dc2626,stroke:#991b1b,stroke-width:3px,color:#fff classDef strong fill:#ea580c,stroke:#c2410c,stroke-width:2px,color:#fff classDef medium fill:#ca8a04,stroke:#a16207,stroke-width:2px,color:#fff classDef weak fill:#2563eb,stroke:#1d4ed8,stroke-width:2px,color:#fff classDef weakest fill:#059669,stroke:#047857,stroke-width:2px,color:#fff class SS strongest class S,L strong class RR,SI,SEQ,CAUSAL medium class CS,MAV,RC,WFR,PRAM weak class MR,MW,RYW,RU,EC weakest

Key Relationships

  1. Strict Serializable is the strongest model, implying both:
    • Serializable (for transactions)
    • Linearizable (for real-time ordering)
  2. Sequential Consistency is implied by linearizability but doesn't require real-time ordering
  3. Causal Consistency preserves causality but allows concurrent operations to be reordered
  4. Session Guarantees (Monotonic Reads/Writes, Read Your Writes) provide per-process consistency

Availability Trade-offs

CAP Theorem Context

The stronger the consistency model, the less available the system can be during network partitions.

Availability Classifications:
  • Not Available: Strict Serializable, Linearizable, Sequential
  • Sticky Available: Read Your Writes, Monotonic Reads/Writes
  • Totally Available: Eventual Consistency, some weak models
Simple Analogy: Think of consistency vs. availability like accuracy vs. speed in journalism:
  • High Consistency: Like a newspaper that fact-checks everything (slow but accurate)
  • High Availability: Like social media news (fast but potentially inconsistent)

Real-World Applications

When to Use Each Model

Strict Serializable:
  • Financial systems (bank transfers)
  • Inventory management
  • Any system where correctness is critical
Linearizable:
  • Configuration systems
  • Leader election
  • Coordination services (like Zookeeper)
Sequential Consistency:
  • Distributed caches
  • Replicated state machines
  • Systems where global ordering matters but real-time doesn't
Causal Consistency:
  • Social media feeds
  • Collaborative editing
  • Chat systems
Eventual Consistency:
  • DNS systems
  • Content delivery networks
  • Shopping cart systems

Summary

Consistency models form a hierarchy from strongest (Strict Serializable) to weakest (Eventual Consistency). The choice of consistency model involves trade-offs:

Key Trade-offs:
  • Stronger models provide better guarantees but limit availability and performance
  • Weaker models offer better availability and performance but fewer guarantees

Understanding these models helps you choose the right consistency level for your application's needs, balancing correctness requirements with performance and availability constraints.

Key Insight: Different parts of your system might need different consistency models - you don't need to apply the same model everywhere. A shopping cart might use eventual consistency, while payment processing requires strict serializability.
← Back to Overview Try Interactive Demo →