What is strict serializability, and why is it considered strictly stronger than either serializability or linearizability alone?

## What it guarantees **Strict serializability** is the guarantee that a system's execution of concurrent, multi-object transactions is equivalent to some serial (one-transaction-at-a-time) execution, and additionally that this equivalent serial order respects real, wall-clock time: if transaction `T1` completes before transaction `T2` is invoked, `T1` must be placed before `T2` in the serial order. It is, by construction, the conjunction of two separately-useful-but-individually-incomplete guarantees: - **Serializability alone** gives you the "as if run one at a time" property across multiple objects, but is silent on timing — an implementation is free to choose any consistent serial order, including one that contradicts real-world sequence. - **Linearizability alone** gives you the real-time property, but its standard definition is scoped to a single object; it says nothing about atomically coordinating a read or write that spans several objects in one transaction. Strict serializability is the union: multi-object transactional atomicity, ordered consistently with the clock on the wall. ## Why the combination matters The reason this combination matters is that most people's intuitive mental model of "a database" silently assumes both properties simultaneously, and systems that provide only one of them can violate that intuition in subtle, hard-to-reproduce ways. Consider an **out-of-band communication channel**: a user completes a bank transfer through one client, hangs up, and calls a support agent, who queries the balance a moment later through a different session, possibly hitting a different replica or node. - **Under strict serializability**, the support agent is guaranteed to see the transfer, because the transfer's commit happened, in real time, before the query began. - **Under serializability alone**, the database is permitted to serve the query using a serial order in which the query is treated as happening "before" the transfer, even though it started afterward in real time, as long as that ordering is internally self-consistent — which is entirely legal for the guarantee as formally defined, but surprising and often unacceptable in production. ## The cost of upgrading The cost of upgrading from serializability to strict serializability is what makes this a genuine engineering **trade-off** rather than a free strengthening. Plain serializability can be implemented with purely local, logical mechanisms — none of which require any notion of physical time or cross-datacenter coordination beyond what correctness already demands: - **two-phase locking**; - **timestamp ordering** with a logical clock; - **optimistic validation**. Strict serializability additionally requires the system to know, with confidence, the real-time ordering of events that may have occurred on physically separate machines with imperfectly synchronized clocks. Google Spanner's solution, `TrueTime`, is the canonical illustration of the price paid: `TrueTime` exposes not a single timestamp but a confidence interval [earliest, latest] bounding true physical time, and Spanner's commit protocol includes a deliberate **"commit-wait"** delay equal to that uncertainty interval before a transaction's effects become externally visible, specifically to guarantee that no other transaction could have started, from Spanner's perspective, before this one's real commit instant. That wait is pure overhead whose entire purpose is buying the real-time guarantee that plain serializability does not need. ## The failure mode The failure mode of not recognizing this distinction shows up as intermittent, hard-to-explain "the database showed me the wrong order of events" bug reports, usually surfacing through some side channel outside the database's own consistency boundary: - a phone call; - a support ticket; - a downstream message queue; - a log correlation. In each, a human or another system observed two events in one order in the real world but the database's serializable-but-not-strict ordering told a different, though logically valid, story. It's also a common trap in system design interviews: candidates who reach for "we'll use a serializable isolation level" as if that alone solves cross-region, real-time consistency requirements are missing that serializability was **never designed to make that promise**; it takes the additional, explicitly engineered real-time layer to get there. ## How to hold the two apart A useful way to hold the two apart going forward: - **Serializability** is a claim about logical equivalence to some serial history. - **Strict serializability**, and linearizability underneath it, are claims about that history also matching physical reality. Systems should only pay for the strict version when a real external observer — a human, another service, an audit trail — can plausibly compare "what happened when" against wall-clock time and would be misled by a merely serializable-but-reordered answer.