When a business asks for an integration between its ERP, CRM, and website, the request almost always arrives with two words attached: real time. It sounds like the obviously correct answer. Instant is better than delayed, so sync everything the moment it changes.
In practice, real-time-everywhere is one of the more expensive default decisions a mid-market company can make. It multiplies the number of failure modes, drives up API and compute usage, and makes debugging significantly harder — often for data nobody looks at until Thursday. The better question isn't "how fast can we sync?" It's "what decision does this data drive, and how quickly does that decision need to be made?"
Start With the Decision, Not the Data
Every field you move between systems exists to support a decision or an action. Inventory availability drives whether a customer can add an item to their cart. Order status drives whether your support rep can answer a phone call confidently. A customer's updated mailing address drives whether next month's invoice arrives.
Those three examples have wildly different urgency. The first one fails visibly and immediately if it's stale — you oversell and disappoint a buyer. The second one causes friction but recovers with a quick manual lookup. The third one has weeks of slack.
Work through your integration field by field and ask three things: Who is waiting on this? What happens if it's an hour old? What happens if it's a day old? You'll typically find that a small minority of your data genuinely needs to move within seconds, and the rest is comfortable on a schedule.
The Cadence Menu
Most integrations end up using a mix of these patterns rather than picking one:
- Event-driven (webhooks): The source system pushes the moment something changes. Best for high-urgency, low-volume events like a new order or a payment confirmation.
- Near-real-time polling: A job checks for changes every few minutes. Less elegant than webhooks but far more forgiving, and it works with systems that don't offer reliable event notifications.
- Scheduled batch: Hourly, nightly, or weekly runs that move larger sets of records. Ideal for financial postings, reporting extracts, and reference data like product catalogs or cost updates.
- On-demand lookup: Don't copy the data at all. Query the source system when someone actually needs it. This is the most underused option and often the cleanest one.
That last pattern deserves emphasis. A surprising amount of integration work exists to replicate data into a second system so a person can look at it there. If the two systems can talk on demand — an embedded view, an API call behind a button — you avoid the entire category of sync drift and reconciliation problems.
What Real Time Actually Costs
Instant sync isn't just faster; it's structurally different. Once you commit to event-driven flows, you inherit a set of engineering problems that batch jobs mostly avoid.
You have to handle out-of-order arrival, because events don't always land in the sequence they occurred. You need idempotency, so a duplicate delivery doesn't create a second invoice. You'll hit API rate limits during bursts, which means queues and backoff logic. And when something goes wrong at 2 a.m., you're diagnosing a stream of individual events rather than a single job with a clear log and a clear rerun button.
None of that is a reason to avoid real time where it's warranted. It's a reason to spend that complexity budget deliberately, on the flows that earn it.
Write a Data Contract for Each Flow
The most useful artifact in an integration project is a plain-language table, one row per flow. Source system, destination system, which records, which direction, cadence, and — critically — the acceptable staleness. "Customer credit limit: ERP to website, hourly batch, must be no more than 90 minutes old."
This does three things. It forces the business to state what it actually needs instead of asking for maximum speed by reflex. It gives engineers a target to build and test against. And it becomes your monitoring spec: if a flow exceeds its stated staleness window, that's an alert worth waking someone for.
Cadence choices also need a reconciliation plan regardless of speed. Real-time flows drift too — they just drift quietly. A daily or weekly comparison that counts records and totals on both sides catches problems that per-event error handling misses entirely.
Direction Matters as Much as Speed
One more decision hides inside cadence: which system owns each field. Bidirectional sync at high frequency is where integrations go to die, because two systems editing the same record concurrently will eventually disagree and there's no clean way to arbitrate.
Pick a single source of truth per field. Let the other system read it. If both genuinely need write access, define which one wins on conflict and log every override so someone can review the pattern later.
Getting cadence right is the difference between an integration that quietly does its job for years and one that generates a weekly fire drill. If you're mapping out how your ERP, CRM, and website should talk to each other — or untangling a set of syncs that already exist — we'd be glad to walk through it with you. Reach out to Infraxio and we'll help you decide what truly needs to be instant.