A customer places an order, gets a confirmation and then sees an old order count in their account. A few seconds later, the display catches up. Nothing necessarily broke. But replace an order count with an available account balance, and the same delay can have serious consequences.
That is the real question behind eventual consistency. Different representations of data may disagree for a while before converging. The word “eventually” is not a product requirement. The business needs to know how long a delay is tolerable and what users are allowed to do in the meantime.
Which copy of the data is behind?
One system commits the change while other systems receive it through messages, replication or scheduled updates. While the change is travelling, different participants may read different versions. That is not automatically lost data; it may simply be data that has not yet propagated.
Suppose the warehouse has reserved the last item while the search catalogue still shows it as available. The next customer can browse that stale catalogue, but the order-taking operation must check the authoritative reservation state again. A delayed search index should not decide whether stock can be sold.
Some experiences can show “updating” or immediately display the confirmed result of the customer's own command. Other operations need a strict check at the moment the business state changes, even if the surrounding screens refresh asynchronously.
Does the customer need to see the change immediately?
There is no single acceptable delay for an entire product. Notification counters may lag with little consequence. Payment status needs clear communication. Available funds and preventing duplicate charges demand much stronger safeguards.
It helps to distinguish guarantees. A user may need to read back their own confirmed write — often called read-your-writes. Critical commands may require strong consistency, while search and reporting remain eventually consistent. One application can use different consistency models for different tasks.
“It will catch up at some point” is not a sufficient answer when the company has not decided what the user can safely do before it catches up.
What actually makes replicas converge?
Lag does not fix itself by magic. A permanently lost event, a failed consumer or an incorrect conflict-resolution rule can leave data inconsistent indefinitely.
Reliable propagation, replay, idempotent consumers, reconciliation and monitoring of data age are all part of making convergence credible. Concurrent updates also need thought: an old event must not blindly overwrite a newer state.
With CQRS, the team should be able to rebuild derived views and explain what the customer sees before they have caught up. Measuring response time alone will not reveal a fast screen showing outdated information.
Define the agreement before choosing the database
I would start with the user journeys. Which ones can tolerate a little lag? Which ones must validate current state before committing an action? Then I would agree on the acceptable delay, the user experience when it is exceeded, and the recovery procedure.
There also needs to be an owner of the business outcome. Somebody must be able to explain which records are out of sync, how long they have been wrong and how they will be repaired. Otherwise a technically elegant asynchronous system becomes a support problem.
Eventual consistency is not permission to show wrong information indefinitely. It is a deliberate trade: less coordination in exchange for controlled delay and explicit safeguards where the delay matters.