Consistency

Consistency describes how up-to-date data is across all nodes in a distributed system.

Strong Consistency

Write: Client A writes X = 1 to Node 1

Before acknowledging write:
Node 1 ──── Replicate ────→ Node 2 (confirms)
                           Node 3 (confirms)

After all confirm:
Node 1: X = 1  ✓
Node 2: X = 1  ✓
Node 3: X = 1  ✓

Read from ANY node returns X = 1

Eventual Consistency

Write: Client A writes X = 1 to Node 1

Immediately after write:
Node 1: X = 1  ✓
Node 2: X = 0  (old value)
Node 3: X = 0  (old value)

After some time (milliseconds to seconds):
Node 1: X = 1  ✓
Node 2: X = 1  ✓
Node 3: X = 1  ✓

Read from different nodes may return different values temporarily

Comparison

Aspect	Strong Consistency	Eventual Consistency
Read after write	Always returns new value	May return old value
Performance	Slower (must replicate)	Faster (write and return)
Availability	Lower (must wait for replicas)	Higher (always available)
Use case	Banking, inventory	Social media, analytics
Protocol	Raft, Paxos	Gossip protocol

Read-Your-Writes Consistency

Client A writes X = 1
Client A reads X → Always returns 1 (even if other nodes lag)

Client B reads X → May return 0 or 1 (depending on which node)

This is a middle ground between strong and eventual consistency.

Different consistency models offer different guarantees about data visibility.

Consistency Model Spectrum

Stronger ←──────────────────────────────────→ Weaker

Linearizability > Sequential > Causal > Eventual

Linearizability: Most strict, most expensive
Eventual: Most relaxed, most performant

Consistency Models

Model	Guarantee	Performance	Use Case
Linearizability	All operations appear instant	Slow	Financial, inventory
Sequential	Operations appear in some order	Medium	Chat, collaboration
Causal	Causally related ops in order	Medium	Social feeds
Eventual	All nodes converge eventually	Fast	Analytics, caching

Linearizability

Timeline:

T1: Client A writes X = 1
T2: Client B writes X = 2
T3: Client C reads X → Must see 2 (or later)

All reads see the most recent write.
Equivalent to single-node performance.

Causal Consistency

Scenario: Social media post

T1: User A posts "Hello" (causes User B's reply)
T2: User B replies "Hi there"
T3: User C reads feed

Causal consistency ensures:
- If User C sees "Hi there", they also see "Hello"
- Causally related events appear in order

Eventual Consistency Details

Write to Node 1:
Node 1: X = 1 (immediately)
Node 2: X = 0 (stale)
Node 3: X = 0 (stale)

Gossip Protocol:
Node 1 gossips to Node 2: "X = 1"
Node 2 updates: X = 1
Node 2 gossips to Node 3: "X = 1"
Node 3 updates: X = 1

Convergence: All nodes eventually have X = 1
Time to converge: Typically milliseconds to seconds

Consistency in Practice

System              Consistency Model
──────────────────────────────────────
Banking             Linearizability
Inventory           Linearizability
Chat                Sequential
Social Feed         Causal
Analytics           Eventual
DNS                 Eventual
Cache               Eventual

Choosing consistency level involves tradeoffs between correctness, performance, and availability.

The Tradeoff Triangle

        Consistency
           /\
          /  \
         /    \
        /      \
       /________\
  Availability  Performance

You can optimize for two, but not all three.

Common Tradeoffs

Scenario	Choose	Tradeoff
Banking	Strong consistency	Lower performance
Social media	Eventual consistency	May show stale data
Shopping cart	Read-your-writes	Complex implementation
Analytics	Eventual consistency	May miss recent data

Consistency vs Performance

Strong Consistency:
- Write must replicate to all nodes before acknowledgment
- Latency = Network RTT × Number of nodes
- Throughput limited by slowest replica

Eventual Consistency:
- Write acknowledged immediately
- Background replication
- Higher throughput, lower latency

Example:
100ms network RTT, 3 replicas

Strong: Write takes 200ms (wait for 2 replicas)
Eventual: Write takes 10ms (local write only)

Consistency vs Availability

Strong Consistency:
- If replica is down, write may fail
- System becomes unavailable during network partitions

Eventual Consistency:
- Write succeeds even if replicas are down
- System remains available during partitions

CAP Theorem: You can only have 2 of 3:
- Consistency
- Availability
- Partition Tolerance

Design Decisions

Q: What consistency level do you need?

A: It depends on the use case:

1. Can you tolerate stale data?
   - Yes → Eventual consistency
   - No → Strong consistency

2. Is availability critical?
   - Yes → Eventual consistency
   - No → Strong consistency OK

3. Is performance critical?
   - Yes → Eventual consistency
   - No → Strong consistency OK

4. Are operations causally related?
   - Yes → Causal consistency
   - No → Eventual consistency