Sequential Consistency: Order Matters, Time Doesn't

A Slightly Weaker Guarantee

Sequential Consistency is slightly weaker than linearizability. It doesn't care about the exact real-time wall clock. Instead, it cares that everyone sees the same sequence of operations, and that each client's operations appear in the order that client issued them.

The definition has two parts:

1. The result of execution is the same as if all operations were executed in some specific sequential (total) order.
2. The operations of each individual client appear in that sequence in the order specified by its program (program order is preserved).

Example: Two Clients, One Variable

• Client A: Writes x = 1, then writes x = 2.
• Client B: Reads x at some point.

Under Linearizability: If A finishes writing 2 before B reads, B must read 2. Real-time ordering is enforced.

Under Sequential Consistency: B could read 1, and then later read 2. This is allowed as long as all other clients also see the transition from 1 to 2 happen in that order. What's forbidden is for B to read 2 and then later read 1 — that would violate Client A's program order, which must be preserved globally.

The key difference: sequential consistency allows stale reads relative to real time, as long as the history of operations is consistent and ordered the same way for everyone. There is no global clock constraint — only a global ordering constraint.

Where It Appears

Sequential consistency is commonly discussed in the context of CPU memory models and multi-processor systems. When a CPU reorders memory operations for performance, it may provide sequential consistency guarantees to the programmer. In distributed databases, it's less common than linearizability or causal consistency, but it appears in some shared-memory distributed systems and certain academic database designs.