Distributed systems · advanced
Strong and eventual consistency
Here, strong consistency means linearizability: operations fit one real-time-respecting single-copy order. Eventual consistency permits temporary divergence but promises replicas converge if updates stop and communication continues.
Why it matters
The chosen consistency model determines which stale or reordered observations clients must tolerate and what latency, availability, or coordination cost the system pays.
Mental model
How to reason about strong and eventual consistency
A write propagates through multiple copies. Strong reads coordinate enough to honor the stated order; eventual reads may reach a lagging copy, so the application must reconcile temporary disagreement.
Analogy
A centrally updated departure board makes everyone wait for one confirmed schedule; separately refreshed boards answer sooner but may disagree until the next successful refresh.
Examples
See the boundary, not just the happy path
Worked example · Read after write
update a password, then immediately verify itThis workflow may require a read-your-writes or stronger session guarantee so the user does not observe the previous value.
Worked example · Eventually convergent counter view
regional analytics dashboards lag briefly after an eventIf temporary staleness is acceptable and replicas converge, eventual reads can reduce coordination on the display path.
Useful contrast · Eventual is not unbounded neglect
a partitioned replica never reconnectsConvergence assumes updates stop and communication succeeds. A permanently unreachable replica cannot satisfy that liveness condition.
Common mistakes
Misconceptions to remove early
Calling eventual consistency random
A system still has documented conflict, ordering, and convergence rules. Clients should design against those guarantees rather than assume arbitrary behavior.
Treating consistency as one database-wide switch
Guarantees can differ by operation, key, session, replica, or configuration. State the exact observation property the workflow needs.
Quick check
Can you predict the result?
1. What does eventual consistency promise under its convergence assumptions?
- • If updates stop and communication continues, replicas converge to a consistent value
- • Every read immediately returns the newest write
- • Conflicting writes can never occur
2. Why might a user-facing write flow need more than an eventual read?
Keep building