Sequential consistency guarantees a single global order of operations that all processes agree on, but unlike linearizability it doesn't require that order to respect real-time (wall-clock) ordering across processes. Why would a system designer choose sequential consistency over linearizability, and what real-time anomaly does that trade-off allow?

## The definition Sequential consistency, introduced by **Leslie Lamport** in 1979 in the context of multiprocessor memory models, requires that there exist some single total order of all operations issued by all processes, such that: 1. every process's own operations appear in that order in the same sequence it issued them, and 2. every process observes operations happening in that same total order. Crucially, unlike linearizability, sequential consistency drops any requirement that this total order respect real, wall-clock time. **Linearizability additionally demands**: if operation A completes in real time before operation B begins, then A must appear before B in the order every observer sees. Sequential consistency has no such rule; it only requires internal consistency, one agreed order respecting each process's own sequence, not alignment with an external clock. ## What an implementation is allowed to do Mechanically, this distinction changes what an implementation is allowed to do. - **A linearizable system** must ensure that once a write is acknowledged complete, no subsequent read in real time from any process can return an older value, which typically forces real-time-respecting synchronization such as waiting for a quorum acknowledgment or routing operations through a leader with a fresh lease. - **A sequentially consistent system** is free to reorder or delay how it makes operations visible relative to real time, as long as it maintains one globally agreed story that respects each individual process's own local ordering — for instance it could batch and reorder writes for efficiency, or use loosely synchronized clocks, as long as the final total order it presents to every observer is internally coherent. ## Why a designer reaches for it, and why the promise disappoints The reason a designer might reach for sequential consistency is the theoretical promise that dropping the real-time constraint should be cheaper than linearizability, since fewer synchronization mechanisms are strictly required. In practice this promise is often disappointing: sequential consistency still requires every replica to agree on a single global order for all operations, including operations from processes that have never communicated, and achieving that kind of global agreement across geo-distributed replicas typically still requires a consensus protocol, a global sequencer, or a single serializing leader — close to the same coordination cost linearizability pays. ## The anomaly it permits The concrete anomaly sequential consistency permits, that linearizability forbids, is this: 1. process `P1` finishes write `W` in real time at `T1`; 2. process `P2`, whose read starts at `T2` strictly after `T1`, is still allowed to see the value from before `W`, as long as the overall order the system settles on remains internally coherent. Sequential consistency only promised a coherent story, not a promise that if it's over, it's visible. ## The trade-off The trade-off, then, is subtle and worth stating precisely: sequential consistency buys a weaker guarantee, no real-time ordering, without necessarily buying a proportionally cheaper implementation, because the expensive part, global agreement across all replicas, is largely unavoidable either way. This is why sequential consistency is comparatively rare as an explicit target for distributed databases: designers who want real coordination savings usually go further down the spectrum to causal consistency, which drops the requirement to order unrelated operations at all, genuinely removing coordination for the common case, or all the way to eventual consistency, rather than stopping at sequential, which keeps most of the cost while giving up the most intuitive guarantee. ## Where it fits, and where it does not - **The classic anti-pattern.** In production, a team that migrates from a linearizable configuration to a sequentially consistent one expecting a big latency win is a classic anti-pattern: the measured improvement is often small, because the system still needs a way to agree globally on one order, and that mechanism, a sequencer, a leader, or a consensus round, dominates the latency budget regardless of the real-time relaxation. - **Where it genuinely shines.** Where sequential consistency genuinely shines is in a different setting: multiprocessor and multi-core CPU memory models and certain in-memory concurrent data structures, where a single machine can cheaply establish and broadcast one global instruction order to its cores without the cross-datacenter network latency that makes the distributed-database case expensive. It is a model born out of hardware memory ordering, and its most successful uses remain much closer to that origin than to globally-replicated cloud databases.