Topic 13.5
Linearizability
In one line
The precise form of strong consistency — operations take effect at a single point in real time.
Think of it like this
A queue at a single ticket counter where everyone can see whose turn is next in the exact real order it happened, with no confusing 'wait, I was clearly before them' moments.
Key ideas
- 01
Intuition: every operation appears atomic at some instant between invocation and response; the sequence matches real time.
- 02
Test: a history is linearizable if you can order all operations so each response came after a consistent state.
- 03
Distributed ≠ linearizable by default: two clients on different replicas can observe different orders.
- 04
Atomic register = the canonical linearizable object; locks, counters, reads with r.y.w. are linearizable in a DB.
- 05
Systems that offer it: single primary DBs, etcd (Raft), Spanner (TrueTime).
- 06
Interview: contrast 'linearizable write' (needs the primary/quorum) with 'sequential consistency' (per-client order, easier at scale).
Explain without notes
Why is 'A writes 5, B reads 4' impossible in a linearizable system — and possible in an eventually consistent one?
Practice
Design the linearizable counter (single primary) + the eventually-consistent counter (Redis INCR at edge?) and the gaps.
Trade-offs
- ↔
Linearizability ≈ the strongest single-copy illusion; the quota is availability + latency.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can explain linearizability with invocation/response timing, and name who provides it.