Back to roadmap
Module 3 · Consistency & ReplicationDay 02220 min

Eventual Consistency

All replicas converge — eventually.

← PreviousNext →
Day 022

Eventual Consistency

Writer
client
Primary
service
Replica
datastore
Replica
datastore
Signal path
Eventual consistency over async replication
Writer
client
flow
Primary
service
Primary
service
async
Replica
datastore
Primary
service
async
Replica
datastore
Memory hook

Eventual Consistency: all replicas converge

Mental model

choose the failure mode you can explain

Design lens

Lower coordination → far higher throughput.

Recall anchors
DefinitionSafe forUnsafe for

Why it matters

Eventual consistency means if no new writes occur, all replicas eventually return the same value. It says nothing about how long 'eventually' is, or what intermediate reads see. That ambiguity is what makes it cheap — and what bites teams that misuse it.

Deep dive

Convergence requires every write to be propagated and a deterministic merge rule (LWW, CRDT, vector clock + reconciliation).

Time bounds matter for users: <100ms is invisible, >1s is a UX problem, multi-second invites bug reports.

Eventual is fine for likes, follower counts, view counts; risky for inventory, balances, anything billed.

Demo / scenario

Like count on a popular post.

  1. Counter incremented in-memory at edge.
  2. Periodic flush to durable store.
  3. Other users see staleness up to flush interval.
  4. Convergence is acceptable; users don't notice.

Tradeoffs

  • Lower coordination → far higher throughput.
  • Possible double-count without idempotency.
  • Hard to reason about in tests — explicit fixtures needed.

Diagram

asyncasync
Writer
Primary
Replica
Replica
Eventual consistency over async replication.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →