I do not treat eventual consistency as a license to confuse users. I use it when the business can tolerate read delay, and I recommend making that delay visible in metrics and user experience.
The question is how long eventual takes
When I talk about "The question is how long eventual takes", I am really asking what Eventual Consistency does when a message is late, duplicated, or missing.
A profile picture can take seconds to appear everywhere. A payment status should not drift without a clear pending state. The architecture needs to show what was accepted, what is still propagating, and what users can safely do in the meantime.
Order status example
I use "Order status example" to keep Eventual Consistency grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
A customer changes a shipping address. The write succeeds in the account service. Search and notification views update a few seconds later from events.
Reconciliation code
When I show "Reconciliation code", I want the code in Eventual Consistency to reveal the production decision, not just the syntax.
A consumer updates a read model after the source write is complete:
void onAddressChanged(AddressChanged event) {
searchView.updateAddress(event.customerId(), event.newAddress());
notificationView.updateAddress(event.customerId(), event.newAddress());
}The handler updates read models after the source event. The system accepts that search and notification views may lag, but they converge from the same event.
Sequence diagram: a change catches up
The source of truth changes first. Other views become correct after they consume the event.
The user promise
- Show pending states when users might notice delay.
- Track propagation lag as a real production signal.
- Do not use eventual consistency for decisions that cannot tolerate stale reads.