Eventual Consistency: What Users Will Notice

When two business systems are kept in sync, there is always a moment when they disagree. A customer's address has been updated in the CRM but not yet in the accounting system; an order has been placed on the website but does not yet show in the warehouse system. In a well-built integration, that moment is short and the systems converge. That property has a name: eventual consistency. Most integrations between separate systems work this way, whether or not anyone designed for it. This guide explains what eventual consistency means in practice, where users will notice the delay, which reads need fresher data and how to measure and communicate sync delay.

What eventual consistency means

In an article on his blog, Werner Vogels describes eventual consistency as a specific form of weak consistency in which the storage system guarantees that, if no new updates are made to an object, eventually all accesses will return the last updated value (All Things Distributed: Eventually Consistent). He calls the period between an update and the moment every observer is guaranteed to see it the inconsistency window, and notes that without failures its maximum size depends on factors such as communication delays, system load and the number of replicas.

The article was written about large distributed storage systems, but the ideas map directly onto business integrations. Each synced system is like a replica, the sync process is the replication and the inconsistency window is the time it takes for a change in one system to appear in the other.

Why integrations are eventually consistent

Keeping separate systems perfectly in step would mean updating all of them in one transaction, which is rarely possible across different products and vendors. Instead, a change is made in one system and then propagated: through a webhook, a queue, a scheduled job or change data capture. Each step takes time and can be delayed by retries, rate limits or outages. The result is a window, sometimes seconds and sometimes hours, during which the systems disagree.

Where users will notice

The window matters most where a person or process reads data shortly after it was changed elsewhere. Common examples:

• A rep updates a customer in the CRM and immediately raises an invoice in accounting, which still has the old details
• A customer pays online and calls support, who see the invoice as unpaid
• A product goes out of stock in the warehouse system while the website still accepts orders
• A user saves a form and the confirmation page reads from a replica that has not caught up

List these situations for your own integrations, ideally with the teams who experience them, since they often know where delays cause rework. They show where the inconsistency window has business consequences and where it does not.

Eventual consistency and fresh reads

Not every read needs the latest data. Classify reads by how fresh they must be:

• Must be current: decisions involving money, stock or permissions, such as accepting an order or approving credit
• Should reflect the user's own change: screens a user sees right after saving
• Can be slightly behind: reports, dashboards, search results and lists

Vogels describes several stronger variants that help with the middle category. Read-your-writes consistency means a process that updated an item always sees the updated value afterwards. Session consistency provides that guarantee for as long as a session lasts. Monotonic read consistency means that once a process has seen a value, it never sees an older one. In integration terms, that might mean showing a user the value they just entered until the sync confirms it, or reading from the system of record for critical decisions instead of a synced copy.

Design around the window

Practical techniques:

• Read critical data from its owner: check stock in the system that owns stock, not a copy
• Show sync status: display when a record was last synced, or a "syncing" label after a change
• Avoid round trips: let the system where a user acts hold the data it needs for that action
• Make actions safe to repeat: if someone retries because they think a change failed, idempotent operations prevent duplicates
• Order and version changes: reject an older update arriving after a newer one

Our guide to sync conflict resolution covers what happens when both systems change the same record during the window.

Worked example: hypothetical freshness requirements

The table below is a hypothetical set of freshness requirements for a company syncing a CRM, an online store and accounting. The targets are illustrative, not recommendations.

Data readWhere it is readFreshness needDesign responseStock for checkoutOnline storeCurrentCheck the stock system at checkoutPayment status for supportCRMWithin minutesWebhook from payment system; show last sync timeCustomer address on new invoiceAccountingReflect latest CRM changeSync on change; finance checks sync status before sendingSales dashboardReporting databaseHours acceptableScheduled loadUser's own profile after savingWeb appRead-your-writesRead from primary database for that user briefly

Measure the inconsistency window

You cannot manage what you do not measure. For each sync, record when a change happened in the source and when it was applied in the target, and track the difference. Watch the typical delay and the worst cases, and alert when delays exceed what the business has agreed. Also monitor backlogs, such as unprocessed messages in a queue, which predict rising delay before users notice. Review the numbers after incidents and releases, when delays are most likely to change.

Decide when real time is worth it

Shrinking the window costs effort: event-driven delivery, more monitoring and handling of ordering and duplicates. For some data, a scheduled sync every few hours is perfectly adequate. Our guide to real-time ERP integration explains how to judge when real-time sync is worth the extra work.

Explain it to users

Users cope well with delays they understand and poorly with ones they do not. Tell teams which data syncs quickly, which syncs on a schedule and where to look for the source of truth. A short note in the CRM, such as "payment status updates within a few minutes of payment", answers the question before it is asked. Review these notes when the integration changes, so the stated delays stay accurate and teams keep trusting them.

Frequently Asked Questions

What is eventual consistency?

It is a model in which separate copies of data may disagree for a time after a change, but converge to the same value if no further changes are made.

What is the inconsistency window?

The period between an update and the moment every reader is guaranteed to see it. In integrations, it is the time a change takes to reach the other systems.

Which data should never rely on an eventually consistent copy?

Data used for decisions involving money, stock or permissions should be read from the system that owns it.

How do I measure sync delay?

Record when each change occurred in the source and when it was applied in the target, track the difference and alert when it exceeds agreed limits.

Design syncs users can rely on

We design integrations that make sync delays visible, keep critical reads accurate and measure how quickly systems converge. See our real-time CRM and database synchronization service, or talk to us about eventual consistency.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.