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:

---

Real-World Examples

Understanding how major companies use different consistency models helps illustrate their practical importance:

Strong Consistency: Banking Systems

The Challenge: Banks need to ensure account balances are always accurate. A user’s balance must be the same across all systems immediately after any transaction.

The Solution: Banks use strong consistency:

• Account Balance: All systems see the same balance immediately
• Transaction Processing: Locks ensure no double-spending
• Critical: Money accuracy is more important than speed

Example: User transfers $100:

• Strong Consistency: Lock Account A → Deduct $100 → Lock Account B → Add $100 → Unlock both
• Result: Both accounts always show correct balance
• Trade-off: Slower (waits for locks), but guaranteed accuracy

Impact: Zero incorrect balances. All transactions are accurate. Critical for financial systems.

Eventual Consistency: Social Media Platforms

The Challenge: Social media platforms need fast user experience. Like counts, comments, and posts need to update instantly, but perfect accuracy across all data centers isn’t critical.

The Solution: Social media platforms use eventual consistency:

• Like Counts: Update immediately on local node, replicate to other nodes asynchronously
• Posts: Write to local node, propagate to other regions within seconds
• Trade-off: Temporary inconsistencies acceptable for speed

Example: User likes a post:

• Eventual Consistency: Update like count locally → Return success → Replicate to other data centers asynchronously
• Result: User sees instant feedback, other users see update within seconds
• Trade-off: Fast response, but temporary inconsistencies possible

Impact: Fast user experience. Handles millions of interactions. Acceptable inconsistencies for non-critical data.

Causal Consistency: Chat Applications

The Challenge: Chat applications need to preserve message order. If User B replies to User A’s message, all users must see the original message before the reply.

The Solution: Chat applications use causal consistency:

• Message Order: Preserves cause-and-effect relationships
• Threads: Ensures replies appear after original messages
• Trade-off: Stronger than eventual, but weaker than strong consistency

Example: User A posts message, User B replies:

• Causal Consistency: Track dependencies → Ensure reply is seen only after original message
• Result: All users see messages in logical order
• Trade-off: Preserves causality without global coordination

Impact: Logical message order. No confusion. Better than eventual consistency for chat.

Hybrid Approach: E-commerce Platforms

The Challenge: E-commerce platforms have different consistency needs for different data types.

The Solution: E-commerce platforms use hybrid approaches:

• Product Catalog: Eventual consistency (fast updates, acceptable inconsistencies)
• Inventory: Strong consistency (prevent overselling)
• Reviews: Causal consistency (preserve reply order)

Example: Product page load:

• Product Info: Eventual consistency (fast, may be slightly stale)
• Inventory: Strong consistency (must be accurate)
• Reviews: Causal consistency (preserve thread order)

Impact: Optimized for different data types. Right consistency model for each use case.

---

Key Takeaways from Real Examples

1. Strong consistency for critical data - Financial, inventory, critical business data
2. Eventual consistency for speed - Social media, analytics, non-critical data
3. Causal consistency for relationships - Chat, comments, threads
4. Hybrid approaches - Use different models for different data types
5. Choose based on requirements - Accuracy vs speed vs relationships

---

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:

Eventual Consistency → Use Version Numbers

For eventual consistency, track versions to detect conflicts:

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?