Linearizability vs. Sequential Consistency
If you use a "Consistent" database, what guarantees are you actually getting? In distributed computing, there are two major models of "Strong" consistency.
1. Linearizability (The Gold Standard)
Linearizability provides a Global Order. It makes the entire distributed system look like a single machine with a single copy of data.
- The Guarantee: Once a write is successful, every subsequent read (from anyone, anywhere) must see that value.
- Cost: Extremely high latency. It requires a total order of events, usually implemented via Raft or Paxos.
2. Sequential Consistency
Sequential consistency is slightly weaker. It guarantees that the order of operations for a single thread is preserved, and that everyone sees the same global order of events, but that order doesn't have to be tied to real-time.
- The Difference: Two users might see a stale value for a short time, but they will never see updates happen in a different order.
3. Which one does your DB use?
- etcd/Zookeeper: Linearizable for reads and writes.
- Postgres (Single Node): Linearizable.
- Cassandra (LWT): Linearizable.
- Standard Cassandra: Eventual consistency (not even sequential).
4. Why this distinction matters in product behavior
Consistency models are not academic labels; they shape user-visible correctness:
- inventory oversell risk
- stale account balances
- double booking in reservation systems
- lock ownership correctness in coordination services
If requirements demand "read your successful write immediately from anywhere," sequential consistency may not be sufficient.
5. Real-time ordering vs logical ordering
Linearizability respects wall-clock order of non-overlapping operations.
Sequential consistency only requires some global order that preserves per-client program order.
That means two operations can be seen in an order that differs from real-time completion, as long as no client's local order is violated.
6. Common misconceptions
- "Strong consistency always means linearizability" -> false
- "Sequential consistency is eventually consistent" -> false
- "Single-leader architecture automatically guarantees linearizable reads" -> only if read path and replication rules enforce it
Always read datastore guarantees in detail, including read modes and failure behavior.
7. Latency and availability implications
Linearizable operations usually require coordination/quorum confirmation, which increases tail latency and can reduce availability during partitions.
Sequential consistency can relax timing constraints and deliver better latency, but may permit brief stale reads relative to real-time.
Choosing model is an SLO decision, not a purely theoretical preference.
8. Where linearizability is usually required
- distributed locks and fencing checks
- leader election metadata
- payment state transitions
- critical uniqueness guarantees (username/seat assignment)
Using weaker consistency here can create irreversible correctness bugs.
9. Where sequential consistency may be acceptable
- collaborative editing streams with conflict resolution
- social feed ranking metadata
- non-critical counters with merge semantics
If temporary staleness is acceptable and ordering is what matters, sequential consistency can be a practical trade-off.
10. Practical database evaluation checklist
Before choosing a datastore/operation mode, verify:
- default read consistency level
- whether reads can be stale after acknowledged writes
- partition behavior (fail fast vs serve stale)
- tunable consistency options per query
- guarantees for multi-key transactions
"Consistent" in marketing docs is never enough for architecture decisions.
Summary
Linearizability is about Time. Sequential consistency is about Order. Understanding this distinction is critical when choosing a consensus store for distributed locking or leader election.
