What is eventual consistency?
Eventual consistency is a guarantee that, if no new updates are made, all replicas of a piece of data will eventually converge on the same value. It does not guarantee when, and it permits reads that return stale data in the meantime.
Why systems accept this. It follows from the CAP theorem: in a distributed system experiencing a network partition, you must choose between consistency and availability. If nodes cannot communicate, either you refuse requests until they can (consistent, unavailable) or you serve potentially stale data (available, inconsistent).
Since partitions are unavoidable at scale, and since unavailability is frequently worse for a business than brief staleness, many systems choose availability.
What it looks like in practice:
You update your profile and see the change, but a colleague loading the page seconds later sees the old version.
A view count that differs between refreshes.
A DNS change taking time to propagate — the most familiar example of all.
A post appearing in one region before another.
Where it is fine: social feeds, view counts, search indexes, recommendations, caches, analytics. Anywhere brief staleness is harmless and availability matters.
Where it is not: financial balances, inventory for a limited item, access control, and anything where acting on stale data causes real harm. These need strong consistency, and the cost is coordination — which means latency and reduced availability.
Useful intermediate guarantees:
Read-your-writes — you always see your own updates, even if others do not yet. This resolves the most jarring user experience and is frequently enough.
Monotonic reads — you never see data go backwards in time.
Causal consistency — operations that are causally related are seen in order, so a reply never appears before the message it answers.
Conflict resolution is the hard part when two replicas diverge — last-write-wins loses data, so CRDTs or application-level merging are often needed.