Back to roadmap
Module 3 · Consistency & ReplicationDay 02125 min

Strong Consistency Models

Linearizable reads see the latest write — at a cost.

Day 021

Strong Consistency Models

Client
client
Leader
service
Replica
datastore
Replica
datastore
Signal path
Strong consistency requires coordination
Client
client
flow
Leader
service
Leader
service
sync
Replica
datastore
Leader
service
sync
Replica
datastore
Memory hook

Strong Consistency Models: linearizable reads see the latest write

Mental model

choose the failure mode you can explain

Design lens

Linearizable lock has ~5–20ms acquire latency cross-zone.

Recall anchors
LinearizableSequentialImplementation

Why it matters

Linearizability is the strongest practical consistency: every read sees the most recent committed write, system-wide. It's expensive — every operation conceptually crosses every replica — but is required for correctness in some workloads (locks, balances, coordination).

Deep dive

Linearizable: total order, real-time ordering matches.

Sequential: total order, but doesn't guarantee real-time order across processes.

Implementations: single-leader with synchronous quorum, or consensus protocols (Paxos, Raft).

Most user-facing apps don't need it; finance, locks, leader election, configuration do.

Demo / scenario

Distributed lock for daily report generation.

  1. Need at most one runner at a time.
  2. Use etcd lease (linearizable).
  3. Acquire lease → run; lose lease → stop.
  4. Coordination is small surface; linearizable is fine.

Tradeoffs

  • Linearizable lock has ~5–20ms acquire latency cross-zone.
  • Lease misses cause double-runs unless app respects fence tokens.
  • Pessimistic locking forbids high contention designs.

Diagram

syncsync
Client
Leader
Replica
Replica
Strong consistency requires coordination.

Mind map

Check yourself

Loading quiz…

Sources & further reading