Topic 13.3
Strong Consistency
In one line
Linearizable behavior: a read after a write always sees the write — the default you assume with one database.
Think of it like this
A bank balance shown on an ATM screen: it MUST show the exact correct number right now, not 'probably correct as of a few seconds ago'.
Key ideas
- 01
Definition: reads return the most recent completed write; the system behaves as if there is one copy.
- 02
Linearizability is the gold standard: every operation appears to take effect at a single instant between its start and end.
- 03
Single-node DBs give it for free (one copy, one clock); distributed replicas must coordinate to fake it.
- 04
How to get it at scale: route reads to the primary, use read-your-writes, use quorum with ordered fences, or choose a linearizable store (etcd, Spanner).
- 05
Cost: coordination = latency, reduced availability under partitions (the CP choice), contention.
- 06
Interview: 'which operations MUST be strongly consistent?' — usually fewer than people think.
Explain without notes
Give three flows where strong consistency is worth its latency, and one where it is not.
Practice
Design 'strong for payment write, eventual for feed' — say where each level is enforced.
Trade-offs
- ↔
Strong = the mental model everyone expects; the cost is exactly what PACELC/partition trade-offs are about.
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 define linearizability and say where the real cost shows up.