You've now met two "strongest" guarantees. In Module 13, linearizable was the strongest consistency model: the system behaves like one copy. Earlier in this module, serializable was the strongest isolation level: transactions behave as if they ran one at a time. They sound like the same promise, people use them interchangeably, and database marketing doesn't help.
They answer different questions, they come from different fields, and a system can give you either one without the other. This short lesson separates them, then puts them together into the guarantee people usually mean when they say "strongly consistent": strict serializability.
Two different questions
Serializable comes from databases. It's about transactions: groups of reads and writes, usually touching many rows. It asks: could the result have come from running these transactions one after another, in some order? It says nothing about which order, and nothing about clocks or real time.
Linearizable comes from distributed systems. It's about single operations on a single object: one read or one write of one key. It asks: does each operation look as if it happened instantly, on one copy, at some moment between when it started and when it finished? That last part is a real-time rule. Once a write has finished, every read that starts afterwards must see it.
| Serializable | Linearizable | |
|---|---|---|
| About | Transactions over many objects | Single operations on one object |
| Promises | The result matches some one-at-a-time order | Each operation takes effect at an instant between its start and finish |
| Real time | Not required. A later transaction can be ordered first | Required. A finished write is visible to every later read |
| Rules out | Lost updates, write skew, phantoms | Stale reads, values going backwards |
| Comes from | Isolation levels | Consistency models |
The cleanest way to see the difference is to find a system that has one and not the other.