Stackbook Logo
decision-makingestablished · medium operational burden

Consistency Model Selection

Also known as: choosing-consistency-level, consistency-level-decision

Intent

Choose the weakest consistency guarantee that still protects each business invariant, per dataset and per operation.

Problem

Teams default to either strongest consistency everywhere, paying latency and availability costs, or weakest everywhere, producing visible anomalies. Neither choice follows from what the business actually needs.

Forces

  • •Stronger guarantees cost latency and availability
  • •Some invariants (balances, inventory, uniqueness) cannot tolerate anomalies
  • •Users notice certain anomalies and ignore others
  • •Data stores offer different menus of guarantees

Solution

Overview

Consistency is a menu, not a switch. Choosing from it well means starting with business invariants rather than database defaults. A shopping cart tolerates seconds of staleness; a payment balance does not. Select the cheapest guarantee that still keeps each invariant true.

Involve product owners, since they know which anomalies customers would actually notice or complain about. Engineers alone tend to over-estimate or under-estimate the harm of staleness.

How it works

Walk through operations and classify them.

Operation              Invariant at risk        Model chosen
debit account          no overdraft             linearizable / strong
show own profile edit  user sees own change     read-your-writes (session)
product view count     none material            eventual
unique username        uniqueness               linearizable on write

Then map each row to concrete settings, such as DynamoDB strongly consistent reads, Cosmos DB session consistency, or quorum sizes in a leaderless store. Publish the mapping so that downstream teams know what to expect. Validate with tests that inject replication lag or partitions.

Pitfalls

  • Deciding per database instead of per operation. One system often needs several levels.
  • Choosing strong for everything out of caution and then paying in tail latency and outage exposure.
  • Choosing eventual without an owner for anomalies and repair.
  • Forgetting that composite flows (read, decide, write) need stronger guarantees than each step alone.
  • Trusting vendor names for levels. Terms like "strong" or "session" differ between products; read the definitions.

Key takeaways

  • Start from invariants and user-visible harm.
  • Pick the weakest model that keeps the invariant true.
  • Decide per operation and document the mapping.
  • Test the choice under replication lag and failure.

✓ When to Use

  • •Selecting a database or tuning its consistency settings
  • •Designing multi-region or replicated architectures
  • •Resolving disputes between product and engineering about staleness

✗ When Not to Use

  • •Single-node ACID databases where one model applies
  • •When the datastore offers only one fixed guarantee
  • •Before the key invariants are known

Pros

  • +Avoids paying for unneeded strong consistency
  • +Ties technical settings to business risk
  • +Makes anomalies an explicit, accepted decision

Cons

  • −Requires analysis of every data flow
  • −Mixed models raise cognitive load
  • −Wrong mapping causes subtle bugs

Cost Profile

Infrastructure

Low: analysis effort

Operational

Medium: per-operation configuration and testing

Cognitive

High: reasoning about anomalies is hard

Failure Modes

  • Using stale reads for a check-then-act sequence, causing overselling

  • Assuming a store default matches the requirement

  • Mixing models without telling downstream consumers

Real-World Examples

Alternatives

  • consistency-model

Related Patterns

  • consistency-model
  • cap-theorem
  • pacelc
  • read-your-writes
  • eventual-consistency
  • quorum-reads-writes

Competency Domains

data staterequirements constraints