Consistency Models

The Consistency Spectrum

Consistency models define the guarantees a distributed system provides for concurrent reads and writes. Stronger consistency means slower operations. Weaker consistency means faster operations but surprising behavior. There is no free lunch — every consistency model is a tradeoff between correctness and performance.

Linearizability

Linearizability is the strongest consistency model. It behaves as if there is a single copy of the data and all operations appear atomic. Once a write completes, all subsequent reads (from any client) see that write. This is the gold standard but requires coordination across nodes.

Linearizable (correct):
  Client A: write x=1 ────────────────────►
  Client B:              read x ──► 1 ✓ (sees A's write)

Non-linearizable (stale read):
  Client A: write x=1 ────────────────────►
  Client B:              read x ──► 0 ✗ (reads old value from follower)

Read-Your-Writes

Read-your-writes guarantees that a client always sees its own writes. After Client A writes x=1, Client A's subsequent read will see x=1. Other clients may still see stale data. This is weaker than linearizability but useful for user-facing applications.

• PostgreSQL: Strong consistency by default (single leader).
• Redis: Read-your-writes with WAIT command.
• MongoDB: Read-your-writes with readPreference: primary.
• DynamoDB: Read-your-writes with strongly consistent reads.

Eventual Consistency

Eventual consistency guarantees that if no new writes are made, all replicas will eventually converge to the same value. This is the weakest model but provides the highest availability and lowest latency. It works for many use cases: social media feeds, DNS, shopping carts.

CAP Theorem

The CAP theorem states that a distributed system can provide at most two of three guarantees: Consistency (all nodes see the same data), Availability (every request gets a response), and Partition tolerance (the system works despite network failures). Since network partitions are inevitable, you must choose between consistency and availability.

PACELC Framework

PACELC extends CAP. It says: if there is a Partition, choose between Availability and Consistency (CAP). Else (no partition), choose between Latency and Consistency. This captures the full tradeoff: even without partitions, consistency costs latency.