Glossary

Eventual Consistency

Eventual consistency allows temporarily different views of data. It is an intentional property with a measurable boundary, not an excuse for arbitrarily incorrect data.

Short definition

A change is valid before every model can see it.

An application may commit a change in one authoritative store and propagate it to other representations asynchronously. For a short period, the order database then says “paid” while reporting, a full-text index, or a read model still shows the previous state. If delivery continues, failures are retried, and no new conflicting writes occur, the derived models eventually converge with the authority.

Eventual Consistency does not say that every intermediate state is acceptable to the business or how quickly convergence happens. Each flow therefore needs its own delay tolerance: seconds may be acceptable for a report, but not for charging a payment twice or checking the last inventory item.

Problem it solves

Distributed parts of a system cannot always change state simultaneously.

A network call, asynchronous consumer, and index update all have latency and can temporarily fail. Immediate global agreement would often require stronger coordination, lower availability, or a slower response.

a read model optimised for fast order display is updated by an event
Elasticsearch receives a product change only after the primary database commits
a cache can return the previous value until expiry or invalidation
reporting and a data warehouse process changes in batches or through a queue
independent services commit their local steps at different times

Practical example and diagram

A paid order and a delayed read model

A payment callback idempotently changes order-42 to paid in the authoritative database. The same reliable integration boundary creates a PaymentConfirmed message, which travels through a queue to the reporting consumer. The API for payment detail can immediately read the authoritative state, while a dashboard built on the read model still shows pending for a few seconds.

The consumer’s first attempt fails because its store is temporarily unavailable. A controlled retry processes the message on the second attempt, changes the read model to paid, and the two views converge again. This window is not an error by itself. An error would be having no expected-delay limit, losing the message without an alert, or telling the user that the older dashboard is authoritative payment confirmation.

Text diagram and its alternative

Authoritative Order DB
order-42 = PAID
      ↓ PaymentConfirmed
Queue
      ↓ Consumer / retry
Reporting read model
PENDING → PAID

How it works

From the authoritative write to convergence

The sequence is the text alternative to the diagram and shows one common implementation, not the only possible consistency model.

Local commit A database transaction stores the order change in the system authoritative for its state. The critical local invariant remains protected immediately.
Asynchronous propagation An event, change feed, or scheduled synchronisation carries the change to derived models. Delay is an expected part of the contract.
Temporarily stale read A read model, index, or another service can return the previous value. The interface should know which source it reads and use an authoritative path for a sensitive decision when necessary.
Retry after failure Retries with backoff and idempotence let the consumer complete the same change without a second business effect. A permanent failure must be traceable.
Convergence The representations agree after successful processing. If concurrent writes can occur at multiple places, the system additionally needs ordering and conflict-resolution rules.

Main parts and principles

Consistency is a specific contract for specific data.

One application can simultaneously use strong local consistency for a payment and eventual consistency for search or reporting.

Authoritative source

It must be clear which system decides the truth of a particular value. Copies, caches, and projections are repaired from it; two unmanaged sources of truth create conflicts that eventual consistency by itself cannot resolve.

Bounded staleness in the application

A business requirement should state an expected delay, such as 99% of changes within five seconds and none older than a minute without an alert. General eventual consistency does not guarantee an upper bound on age.

Read model and projection

A derived model stores data in a shape suitable for a particular query. Its rebuild or repeated processing must respect order, version, and idempotence so that an older event cannot overwrite a newer result.

Delivery and repair

A message queue can absorb an outage and retain a backlog. Merely sending a message is not enough: the system monitors lag, failed messages, dead-letter state, and the ability to run a controlled replay or reconciliation.

User contract

The UI can show a “processing” state, last-updated time, or an optimistic change with a repair path. Read-your-writes can sometimes be provided by reading from the authority or temporarily carrying the newly committed value.

Benefits and limitations

Less coordination introduces a period of uncertainty that must remain visible.

Potential benefits

faster acknowledgement of the primary write without waiting for every derived system
more resilient handling of temporary outages through a backlog and later catch-up
independent scaling of read models, indexes, and integration consumers
models optimised for different queries without extending one global transaction

Limitations and common mistakes

the user interface may briefly show older data or two different states
without an authoritative source there is no safe way to decide which value should prevail
unbounded retries can create an endless backlog and hide a permanent contract error
missing order or version information lets an older message overwrite a newer projection
using eventual consistency for payment or inventory without analysing invariants can cause a real business error

Differences from similar concepts

Eventual consistency is not a transaction, cache, or Event Sourcing.

An ACID transaction protects related changes within a supported local boundary and provides specific isolation behaviour. Eventual consistency describes how separate representations converge over time; it can follow a local ACID commit, but is neither a weaker name for that commit nor a replacement where an invariant must hold immediately for every read.

A cache is a temporary copy primarily intended to speed up reads. It may exhibit eventual consistency, but so can durable read models, replicas, and other services. Cache invalidation is one particular mechanism, not the definition of the consistency model.

Event Sourcing stores state as a history of events. Asynchronous projections over that history are often eventually consistent, but the concepts are independent: eventual consistency can occur without an event store, and Event Sourcing can update a projection synchronously in a simple process.

Operations and UX

Delay must be measured, communicated, and repairable.

“Eventually” is not an operational target. The team needs to distinguish ordinary delay from an incident.

define the authoritative source and consistency requirement for every important value
measure end-to-end lag, oldest-message age, and the difference between the authority and projection
design an idempotent consumer, ordering, and protection against stale writes
show an intermediate state to the user when the result cannot appear immediately
provide reconciliation or rebuild that can bring a derived model back in sync
test delay, duplication, reordering, consumer outage, and a permanently invalid message

Common questions

Eventual consistency in practice

Does Eventual Consistency mean the system returns incorrect data?

Not necessarily. It can deliberately return an older but expected representation. An error is a broken business rule, an exceeded delay tolerance, or a state that will no longer converge without intervention.

How long may synchronisation take?

The term itself provides no upper bound. A particular system must set and measure one according to risk, such as seconds in normal operation with an alert when delay exceeds one minute.

Is eventual consistency the opposite of ACID?

No. A service can store a change in a local ACID transaction and then propagate it asynchronously to eventually consistent models. The terms describe different boundaries and properties.

Is every cache eventually consistent?

Not automatically. Some caches only have a TTL, while others are invalidated or updated at write time. A cache is a kind of copy; eventual consistency describes the expected relationship and convergence of multiple states over time.

What if a consumer never processes one change?

The system then fails to converge and the guarantee is not met. It needs monitoring, limited retries, a traceable failure, and a repair or model-rebuild mechanism.

How I design consistency

I distinguish immediate business rules from data that can safely catch up.

For distributed flows I define the authoritative state, expected delay, UI behaviour, and recovery after a consumer failure.

View my approach to application architecture Discuss your project without obligation