Consistency Models

What is Consistency?

Consistency answers a fundamental question: When you update data in one place, when do other parts of your system see that change?

Think of it like updating a shared document. Do you want everyone to see changes instantly (strong consistency), or is it okay if they see them a few seconds later (eventual consistency)?

Simple Analogy

Imagine a classroom with multiple whiteboards. Strong consistency = everyone writes on the same whiteboard (slow, but everyone sees the same thing). Eventual consistency = everyone has their own whiteboard, and changes are copied around (fast, but temporary differences exist).

---

The Consistency Spectrum

Consistency isn’t binary—it’s a spectrum from strongest to weakest:

---

Model 1: Strong Consistency

Strong consistency guarantees that all nodes see the same data immediately after a write completes.

How It Works

Key Characteristic: The write operation blocks until all replicas confirm. Only then does the client get a success response.

Real-World Example: Bank Account Balance

When Strong Consistency is Required

Financial transactions, inventory counts, and critical state changes typically need strong consistency. You can’t have two people buying the last item in stock!

Trade-offs

Aspect	Strong Consistency
Data Accuracy	✅ Always correct, no stale reads
Write Latency	❌ Higher (waits for all replicas)
Availability	❌ Lower (if one node is down, writes may fail)
Complexity	❌ Higher (need coordination, locks)
Use Cases	Financial systems, inventory, critical state

---

Model 2: Eventual Consistency

Eventual consistency allows temporary differences between nodes, but guarantees all nodes will eventually converge to the same state.

How It Works

Key Characteristic: The write returns immediately after updating the leader. Replication happens asynchronously in the background.

Real-World Example: Social Media Likes

When Eventual Consistency Works

Social media likes, view counts, comments, and non-critical metrics work great with eventual consistency. Users don’t need to see the exact count immediately—they just want fast interactions!

Trade-offs

Aspect	Eventual Consistency
Data Accuracy	⚠️ Temporary inconsistencies possible
Write Latency	✅ Lower (returns immediately)
Availability	✅ Higher (can write even if some nodes down)
Complexity	✅ Lower (no coordination needed)
Use Cases	Social media, analytics, non-critical data

---

Model 3: Causal Consistency

Causal consistency preserves cause-and-effect relationships. If event A causes event B, all nodes that see B must have already seen A.

The Problem It Solves

How It Works

Causal consistency uses vector clocks or logical timestamps to track dependencies:

Key Characteristic: Events are delivered in causal order, even if they arrive out of order.

Real-World Example: Chat Application

When Causal Consistency Matters

Chat applications, comment threads, and collaborative editing benefit from causal consistency. Users need to see messages in logical order, but don’t need global ordering of all events.

Trade-offs

Aspect	Causal Consistency
Data Accuracy	✅ Preserves logical relationships
Write Latency	✅ Lower than strong (no global coordination)
Availability	✅ Higher than strong consistency
Complexity	⚠️ Medium (need dependency tracking)
Use Cases	Chat, comments, collaborative editing

---

Choosing the Right Consistency Model

Decision Framework

Use Case	Consistency Model	Why
Bank balance	Strong	Can’t have incorrect balances
Inventory count	Strong	Can’t oversell products
Social media likes	Eventual	Speed > exact count
View counts	Eventual	Approximate is fine
Chat messages	Causal	Need logical order
Comment threads	Causal	Replies must follow posts
User profiles	Eventual	Can tolerate slight delays

---

LLD ↔ HLD Connection

How consistency models affect your class design:

Strong Consistency → Use Locks

When you need strong consistency, use synchronization primitives:

Python

Strong Consistency with Locks

from threading import Lock

class Account:
    def __init__(self, balance):
        self._balance = balance
        self._lock = Lock()  # Ensures atomic operations

    def transfer(self, amount, to_account):
        # Lock both accounts to prevent race conditions
        with self._lock:
            with to_account._lock:
                if self._balance >= amount:
                    self._balance -= amount
                    to_account._balance += amount
                    return True
        return False

Java

Strong Consistency with Locks

import java.util.concurrent.locks.ReentrantLock;

public class Account {
    private double balance;
    private final ReentrantLock lock = new ReentrantLock();

    public boolean transfer(double amount, Account toAccount) {
        // Lock both accounts to prevent race conditions
        lock.lock();
        try {
            toAccount.lock.lock();
            try {
                if (balance >= amount) {
                    balance -= amount;
                    toAccount.balance += amount;
                    return true;
                }
            } finally {
                toAccount.lock.unlock();
            }
        } finally {
            lock.unlock();
        }
        return false;
    }
}

Eventual Consistency → Use Version Numbers

For eventual consistency, track versions to detect conflicts:

Python

Eventual Consistency with Versions

class Document:
    def __init__(self, content):
        self.content = content
        self.version = 0  # Track version for conflict detection

    def update(self, new_content, client_version):
        if client_version != self.version:
            # Conflict detected - need merge strategy
            raise ConflictError("Version mismatch")

        self.content = new_content
        self.version += 1
        return self.version

Java

Eventual Consistency with Versions

public class Document {
    private String content;
    private int version = 0;  // Track version for conflict detection

    public int update(String newContent, int clientVersion) {
        if (clientVersion != version) {
            // Conflict detected - need merge strategy
            throw new ConflictException("Version mismatch");
        }

        content = newContent;
        version++;
        return version;
    }
}

Causal Consistency → Track Dependencies

For causal consistency, maintain dependency graphs:

Python

Causal Consistency with Dependencies

from typing import List, Set

class Event:
    def __init__(self, data, dependencies: List[int]):
        self.data = data
        self.dependencies = set(dependencies)  # Events this depends on
        self.id = None  # Assigned by system

class EventStore:
    def __init__(self):
        self.events = {}  # id -> Event
        self.seen = set()  # Events this node has seen

    def can_deliver(self, event: Event) -> bool:
        # Can only deliver if all dependencies are seen
        return event.dependencies.issubset(self.seen)

    def deliver(self, event: Event):
        if self.can_deliver(event):
            self.seen.add(event.id)
            # Process event...

Java

Causal Consistency with Dependencies

import java.util.*;

public class Event {
    private String data;
    private Set<Integer> dependencies;  // Events this depends on
    private Integer id;

    public boolean canDeliver(Set<Integer> seen) {
        // Can only deliver if all dependencies are seen
        return seen.containsAll(dependencies);
    }
}

class EventStore {
    private Map<Integer, Event> events = new HashMap<>();
    private Set<Integer> seen = new HashSet<>();

    public boolean canDeliver(Event event) {
        return event.canDeliver(seen);
    }

    public void deliver(Event event) {
        if (canDeliver(event)) {
            seen.add(event.id);
            // Process event...
        }
    }
}

---

Key Takeaways

Remember

• Strong consistency = all nodes see same data immediately (slower, but accurate)
• Eventual consistency = nodes converge eventually (faster, but temporary differences)
• Causal consistency = preserves cause-effect relationships (middle ground)
• Choose based on use case: Financial = strong, Social = eventual, Chat = causal
• LLD implementation: Locks for strong, versions for eventual, dependencies for causal
• Trade-off: Consistency vs Performance vs Availability

---

What’s Next?

Now that you understand consistency models, let’s explore the fundamental theorem that governs these trade-offs:

Next up: CAP Theorem Deep Dive — Learn why you can’t have everything: Consistency, Availability, and Partition tolerance.

Practice Exercise

Think about a system you’ve built: What consistency model does it use? Could it use a weaker model for better performance? What would break if you changed it?