Every integration conversation eventually hits the same line: "We need it to sync in real time." It sounds like a requirement. It's usually a reflex — a stand-in for "I don't want to think about staleness ever again."
But real time isn't a checkbox you flip on a connector. It's a set of commitments: endpoints that stay up, queues that absorb spikes, retry logic that doesn't create duplicates, and someone who notices when a webhook stops firing. Choose it everywhere and you buy fragility you didn't budget for. Choose it nowhere and your sales team quotes from yesterday's inventory. The useful question isn't how fast — it's what breaks if this data is an hour old?
Start with the decision, not the record
Data doesn't have an inherent urgency. Decisions do.
Ask who acts on a given field, and how quickly. If a warehouse picker needs to know an order exists the moment it's placed, that's a real-time trigger. If your controller reviews revenue by product line on Tuesday mornings, nightly is genuinely fine — pushing that data every ninety seconds adds cost and failure modes and changes nothing about the decision.
This reframe kills a surprising number of "real-time" requirements on the spot. A field nobody looks at until the monthly close does not need a webhook.
Sort your flows into three tiers
Most mid-market companies can map every integration they own into one of three buckets:
- Event-driven (seconds): something in the physical or customer-facing world depends on it immediately — order-to-fulfillment handoffs, payment confirmations, inventory availability shown on a live storefront, support tickets routing to on-call.
- Near real time (minutes to hourly): a human will act today but not this instant — new leads flowing from website forms to CRM, quote-to-order status, credit holds, commission-affecting updates.
- Batch (nightly or scheduled): reporting, accounting summaries, product catalog enrichment, historical backfills, anything that feeds a dashboard someone reads on a schedule.
Write your actual flows on a page and assign a tier to each. The list is almost always shorter than people expect, and the top tier is usually three or four items — not thirty.
Batch isn't backward
There's an unfair reputation problem here. Batch processing sounds like mainframes and green screens, so teams reach for streaming to feel modern. In practice, scheduled batch jobs have properties real-time flows have to work hard to earn.
Batch runs are easy to replay. If last night's job failed, you fix the mapping and run it again, and you know exactly what window you're reprocessing. Batch gives you a natural reconciliation point — a moment where you can compare record counts and totals on both sides and catch drift. Batch also smooths load, which matters when you're integrating with an API that throttles you.
Real-time flows lose all three of those comforts. A missed webhook leaves no obvious gap to backfill. A partial failure mid-stream leaves two systems disagreeing with no scheduled moment where anyone would notice.
The pattern most companies land on
After enough implementations, the same architecture keeps winning: a small number of event-driven triggers for the moments that touch customers or physical operations, near-real-time polling for the working-hours flows, nightly batch for everything reporting-shaped — and then a scheduled reconciliation sweep that compares both systems and flags mismatches.
That last piece is the one teams skip, and it's the one that saves you. Reconciliation is what turns "we think the sync is working" into "we know, because something would have told us." It's cheap to build alongside a batch job and awkward to bolt onto a pure event-driven design later, which is another argument for not making everything real time by default.
Questions worth asking your integrator
Before you sign off on an integration design, get plain answers to these: What happens if the destination system is down for two hours? If the same event arrives twice, do we get two records or one? How do we backfill a day we missed? Who or what notices a silent failure, and how fast? What's the schedule for reconciliation, and who reviews the exceptions?
If the answers are vague, the sync speed isn't your real problem.
Where this usually pays off
When we look at integration landscapes across ERP, CRM, and the website, the expensive mistakes are rarely "too slow." They're flows built at the wrong tier — real-time plumbing for reporting data, nightly batch for something a customer sees, and no reconciliation anywhere. Fixing the tiering often reduces both cost and failure rate at the same time, which is a rare combination.
If you're mapping integrations right now — or inherited a set nobody fully understands — we'd be glad to walk through your flows and tier them with you. That conversation tends to be short, and it usually changes the build.