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
I use this section to force the failure case into the conversation, not just the clean path.
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
A practical example makes the hidden cost visible, especially around ownership and recovery.
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
I use the code here to show the decision boundary, not just 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.