Consistency models

Consistency describes what values ​ ​ readers see and in what order during competitive changes. The right choice of model is the balance between rigour of invariants, latency, availability and cost (PACELC). Below is a practical guide to models and their application.

1) "Strict" models

Linearizable (Strong)

Behavior as if all operations were performed instantly in some uniform order that respects real time.
Pros: simple mental model, safe for money and uniqueness.
Cons: quorums/leader → p95/p99 growth, especially interregionally.
Use cases: balances, inventory with hard limits, unique names/keys.

Sequential consistency

All threads see the same order of operations, but the real-time order is not required. Slightly weaker than linearizable, rarely exhibited directly in products.

Serializable

Equivalent to some sequential order of transactions (not individual operations).
Pros: correctness of complex invariants at the query/table level.
Cons: more expensive (blocking/versioning/conflict validation).
Use cases: complex financial transactions, consistent recounts, inventory.

Snapshot Isolation (SI)

Each transaction reads an immutable snapshot over time; entries conflict on "same lines," but write skew is possible.
Pros: fast reads without locks, stable reports.
Cons: not serializable, write skew trap (example: doctors on duty).
Use cases: analytics, reports, most CRUDs without hard invariants.

2) Per-session and causal guarantees

Read-Your-Writes (RYW)

The client always sees it in subsequent readings after his entry.
Pros: good UX (form → confirmation).
Cons: local warranty, not global.

Monotonic Reads / Writes

Readings do not "roll back"; the records of one client are applied in the same order as those sent.

Causal Consistency

If the operation depends on another (A → B), everyone sees A before B.
Pros: intuitive for social feeds, comments.
Cons: Routing and causality labels (vector clocks) are more difficult.
User keys: communications, joint editing, event feeds.

3) Weak and hybrid models

Bounded Staleness

Reads can lag no more than Δ t or N versions.
Pros: predictable UX, good compromise interregionally.
Cons: Doesn't protect against write conflicts.

Eventual Consistency

Over time, all copies converge; order and delay are not guaranteed.

Pros: Minimal latency/cost, high availability (AP)

Cons: Need an explicit merge (CRDT/domain rules).
Use cases: caches, feeds, metrics, likes, nen critical directories.

4) Typical anomalies and what they mean

Dirty Read: reading uncommitted data.
Non-repeatable Read: The same read within a transaction gives different values.
Phantom: upon repeated request, a string matching the predicate appears/disappears.

Write Skew (with SI): two transactions read the intersecting invariant and write different lines, violating the condition "the sum must be ≥ 1."

Lost Update: The record "overwrites" the competitor's changes.

5) Quorums and read/write levels

Many stores allow you to set the'R '/'W 'levels (the number of replicas to read/write).

Quorum (R + W> N) gives "intersection" and strong guarantees of reads of the last record.
W = 1, R = 1 → low latency, but old data is possible.
Tuning: critical operations - high 'W' (or leader), the rest - low 'R' for speed.
Read-repair/Hinted handoff help get consistency in the background.

6) Hours and order: how we "understand" causality

Lamport clocks: partial order of events.
Vector clocks: fix causality, allow detecting conflicts.
Hybrid/TrueTime approaches: limit the spread of clocks in the cluster for transaction ordering and bound-staleness.
Versioning: 'version/ts + actor' for merge; in CRDT, closed semigroups (commutativity/idempotency).

7) CRDT and domain merge

CRDT (converged/replicated data types) guarantee convergence without coordination: G-Counter, OR-Set, LWW-Register, Map, text OT/WOOT variants.
When useful: likes, many tags, baskets, documents.
Limitations: Come up with the correct "merge" semantics for a specific domain entity.

8) Communication with CAP/PACELC

Strict models (Linearizable/Serializable) in the multi-region → CP with increasing latency (PACELC: select C and pay L).
Weak/hybrid models → AP and/or low L, but need merge/conflict-resolution.
Hybrid: CP-kernel for invariants + AP-projections/caches for reads.

9) Model selection: checklist

1. Invariants: what should not be violated? (uniqueness, balance, limits).
2. Regionality: Where are the writes/reads done? (local/global).
3. SLO by latency: p95/p99 for critical pathways?
4. Coordination price: ready to pay with interregional quorums?
5. Conflicts: Do you have a deterministic merge or do you need a coordinator?
6. UX expectations: RYW/monotonic/causal are important for the client?
7. Observability: how do you measure lag/conflict/degree of obsolescence?
8. Folbacks: What happens when a net is split (P)? read-only/local entry/queues?

10) Quick recipes

Payment/balance: Linearizable/Serializable, leader + quorum, short timeouts; RYW readings.
Profiles/feed: Causal/Bounded staleness + cache; CRDT for likes/counts; RYW for author.
Search/Analytics: SI/Read Committed, asynchronous projections, eventual for indexes.
Global SaaS: Geo-partitioning; "home records" - CP, reports/directories - AP.

Co-editing: causal/eventual + CRDT/OT; preserving "history."

11) Consistency observed

Lag metrics: 'replication _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Conflict: percentage of conflicts, average resolution time.
Quorums: success of 'R/W' quorums, timeouts of interregional paths.
Customer warranties: RYW/monotonic - trace tags by session.

12) Typical errors

Demanding Strong "everywhere" without a business basis → an explosion of latency and cost.
Dual-write to different regions without sagas/CRDT → phantoms and loss of invariants.
Ignore RYW/monotonicity in UX → "missing" the data just sent.
Do not track the aging of caches/projections → "eternal" discrepancies.
Ill-conceived merge → unexpected loss/duplicate values.

13) Mini-reference architecture

Write-core (CP): leader, quorum records, SLOs and timeouts, logs.
Read-plane (AP): materialized views, TTL caches, read-repair.
Client: sticky-session/session guarantees (RYW/monotonic), version labels.
Engine conflict: CRDT/domain rules, manual settlement queue.
Monitoring: lags, conflicts, shares of outdated readings.

Conclusion

A consistency model is an engineering contract between data, latency, and availability. Start with invariants and SLOs, choose strictly where you need it, and weaker where you can, not forgetting about customer guarantees, quorums, hours and observability. A competent combination of models gives scale, predictability and sustainability - without sacrificing business truth and user trust.