Stackbook Logo
data-consistencyestablished · low operational burden

Consistency Model

Also known as: consistency-models, consistency-spectrum

Intent

Define the contract between a replicated data store and its clients about which values reads may return and in what order.

Problem

Replicated and concurrent systems can return stale, reordered, or conflicting values. Without a named contract, clients cannot know which anomalies to expect or defend against.

Forces

  • •Replicas update at different times
  • •Concurrent operations have no single global time
  • •Stronger contracts need more coordination
  • •Application code encodes assumptions about ordering

Solution

Overview

A consistency model is a promise about what reads can return given the history of writes. It is the interface between the storage system and the programmer: the stronger the promise, the simpler the application code and the more coordination the system must do.

Each step down the ladder removes a guarantee clients could otherwise rely on, but it also removes coordination that slows writes and blocks during failures. Knowing exactly which guarantee you hold is what lets you design correct clients.

How it works

Models form a rough hierarchy from strongest to weakest.

linearizable          real-time order, single copy illusion
  sequential          one global order, respects per-process order
    causal            cause precedes effect everywhere
      session         read-your-writes, monotonic reads
        eventual      replicas converge if writes stop

Spanner offers external consistency using synchronized clocks and consensus; Dynamo-style systems offer eventual consistency with tunable quorums. Clients written against a weaker model run safely on stronger ones, but not the reverse. Tools such as Jepsen test real systems against their claimed model.

Pitfalls

  • Mixing up consistency (replica agreement) with isolation (transaction interference). ACID's C is a different idea.
  • Assuming "strong" means linearizable. Check definitions.
  • Writing code that silently depends on read-after-write when the store gives only eventual guarantees.
  • Treating the hierarchy as total. Some models are incomparable.
  • Believing documentation without testing; bugs and misconfigurations break claimed guarantees.

Key takeaways

  • A consistency model is a client-visible contract.
  • Stronger guarantees mean simpler clients and costlier coordination.
  • Do not confuse consistency with transaction isolation.
  • Code against the weakest guarantee you actually receive.

✓ When to Use

  • •Evaluating or documenting a datastore
  • •Designing client logic over replicated data
  • •Diagnosing anomalies such as stale or time-travelling reads

✗ When Not to Use

  • •Single-node databases with serializable transactions and no replicas
  • •Quick prototypes where anomalies are harmless
  • •As a substitute for isolation-level reasoning within transactions

Pros

  • +Precise shared vocabulary
  • +Lets clients rely on explicit guarantees
  • +Clarifies cost of each guarantee

Cons

  • −Many overlapping terms confuse teams
  • −Vendors use names inconsistently
  • −Distinct from transaction isolation, which is easily conflated

Cost Profile

Infrastructure

None: conceptual

Operational

Low: documentation

Cognitive

Medium: subtle semantics

Failure Modes

  • Assuming linearizability when the store provides only eventual consistency

  • Confusing isolation levels with replica consistency

  • Relying on vendor labels instead of tested behavior

Real-World Examples

Alternatives

  • eventual-consistency

Related Patterns

  • consistency-model-selection
  • cap-theorem
  • eventual-consistency
  • read-your-writes
  • vector-clocks

Competency Domains

data state