Consistency models: different axes, not one ladder

“Strong” and “weak” hide several independent questions. State the object or transaction, the order being promised, the failure assumptions and the client-visible anomalies.

Linearizability

Linearizability is a real-time correctness condition for concurrent object operations. Each operation appears to take effect at one point between invocation and response, and the total order respects real-time precedence. If a write completes before a read starts, that read cannot return an older value.

A quorum inequality alone is not an implementation proof. Leaders, consensus, read-index or lease rules, version ordering, membership changes and completion acknowledgements determine whether the protocol is linearizable.

Serializability and strict serializability

Serializability is a transaction property: committed transactions have the same effect as some serial execution. It does not by itself require that this serial order respect real-time order between transactions. Strict serializability combines serializability with real-time precedence.

Therefore serializability and linearizability are not simply adjacent rungs. One describes multi-operation transactions; the other describes concurrent object histories, and a system can provide different combinations.

Causal and session guarantees

Causal consistency preserves potential cause before effect: a reply should not become visible before the post it depends on. Unrelated concurrent operations need not receive one global order. Implementations carry dependency/version metadata or make a replica wait until predecessors are visible.

Session guarantees such as read-your-writes and monotonic reads are client-scoped contracts. They may require sticky routing, a session token, waiting, or forwarding to a sufficiently advanced replica. They are not implied by eventual convergence.

Eventual convergence

A useful eventual-consistency contract states the conditions: if updates stop and relevant messages are eventually delivered, replicas converge. Concurrent writes still need a deterministic merge, convergent data type, application conflict, or declared winner. Replication alone does not prevent lost updates.

Database isolation

Isolation levels describe transaction anomalies, not replica freshness:

• PostgreSQL defaults to Read Committed, where each statement sees a snapshot as of that statement.
• Repeatable Read holds a stable transaction snapshot in PostgreSQL and prevents the documented phantom behavior there, but applications must still understand serialization anomalies.
• Snapshot isolation can admit write skew when transactions update disjoint rows after reading a shared invariant.
• Serializable prevents serialization anomalies by blocking, ordering or aborting transactions. Applications must retry serialization failures from the beginning.

External calls inside a retried transaction can duplicate effects. Commit first and publish through an outbox, or use an idempotent external operation and reconciliation.

Scenarios

A later read respects a completed write on one register.

A reply waits for the post identified by its dependency token.

Concurrent commutative updates converge under eventual delivery.

Two disjoint writes violate a cross-row invariant under snapshot isolation.

A serialization failure aborts safely and the whole transaction retries.

Selection checklist

• Name the invariant and the operations that may race.
• Decide whether real-time order, causal order, session order or only convergence is required.
• State the read freshness and replica-routing contract.
• Include timeouts, duplicates, retries and unknown commit outcomes.
• Make conflict resolution deterministic and test it for associativity/commutativity where required.
• Load-test coordination latency and abort rate; correctness guarantees have operational costs.
• Document guarantees per operation, not only per database product.

Primary sources

• Herlihy and Wing, Linearizability: A Correctness Condition for Concurrent Objects: https://www.cs.cmu.edu/~wing/publications/HerlihyWing90.pdf
• PostgreSQL 18, Transaction Isolation: https://www.postgresql.org/docs/18/transaction-iso.html
• PostgreSQL 18, SET TRANSACTION: https://www.postgresql.org/docs/18/sql-set-transaction.html
• Gilbert and Lynch, formal atomic consistency and availability definitions: https://www.cs.princeton.edu/courses/archive/spring21/cos418/papers/cap.pdf