CAP, PACELC and consistency models

Once data lives on more than one machine, every read has to answer one question: how recent must this value be? A single Postgres box answers it for free, because there is one copy. With three replicas across two data centers, the answer costs something. Replicas either wait for each other, which adds latency, or they drift and a reader may see the past.

This topic gives you the vocabulary for that trade-off. It names what you give up during a network split, what you pay on every request, and which guarantee each feature needs.

Concepts in this section

Read the pages in this order. Each one builds on the one before.

The spectrum

Consistency models are promises between a data store and its clients. Stronger models allow fewer outcomes. That makes code easier to reason about, and it costs coordination.

Read the arrows as "gets stronger, costs more coordination." Session guarantees and causal consistency can stay available during a partition. Sequential and linearizable consistency cannot.

Where real systems sit

• Spanner offers external consistency, which is linearizability for transactions. It waits out clock uncertainty on commit, so multi-region writes take tens of milliseconds.
• DynamoDB reads are eventually consistent by default. ConsistentRead: true reads the leader and costs twice as much.
• Cassandra lets each query choose how many of the N replicas must respond. Overlapping quorums make stale reads rare, but they are not a guarantee.
• Postgres is linearizable on the primary. Replicas lag by the replication delay.

Trust, but verify

A vendor's documentation says what it intends. Jepsen, Kyle Kingsbury's testing project, checks what actually happens. It injects partitions, process kills and clock skew, records every operation, and checks the history against the claimed model.

Jepsen has found violations in many systems. Reading its reports teaches you where guarantees break. Failure paths, such as leader changes during a partition, are where acknowledged writes get lost. Normal operation is usually fine.

Common mistakes

• Saying "consistent" with no qualifier. Name the model, for example "linearizable on the seat row".
• Letting an ORM or pooler send reads to replicas by default. That quietly downgrades strong reads to eventual ones.
• Choosing one model for everything. Assign a model per entity instead.
• Trusting the default setting. Many systems offer strong consistency only with non-default settings.

Key takeaways

• Consistency models define which values a reader may see. Stronger means more coordination.
• CAP applies during a partition. PACELC adds the latency cost of agreement the rest of the time.
• Causal consistency is the strongest model that stays available during a partition.
• Isolation and consistency are separate axes. Strict serializability has both at full strength.
• Choose per feature, based on what a stale value costs.

Further learning

Martin Kleppmann's Cambridge lecture on linearizability uses timeline diagrams to define the guarantee precisely.

Jepsen: Consistency ModelsConsistencyjepsen.io DynamoDB read consistency (AWS docs)Explore the differences between eventually consistent reads and strongly consistent reads for tables and indexes in DynamoDB.docs.aws.amazon.com Designing Data-Intensive Applications (Kleppmann)Designing Data-Intensive Applications (DDIA) — an O’Reilly book by Martin Kleppmann (The Wild Boar Book)dataintensive.net