Somewhere between the demo and the build, "real-time" becomes the default. Nobody argues for it; nobody questions it either. It just sounds like what a modern system should do. Then the invoices arrive — more middleware, more monitoring, more engineering hours spent chasing a sync that fired twice during a network blip — and the business realizes it paid a premium for speed nobody uses.
The fix isn't to slow everything down. It's to decide, flow by flow, how fresh the data actually needs to be. That decision has a name: a latency budget. And it's one of the cheapest architectural choices you'll ever make.
Real-Time Is a Cost, Not a Feature
Event-driven integrations are genuinely useful, but they bring a set of obligations that batch jobs don't. You need to handle duplicate events, out-of-order delivery, retries that don't compound the problem, and a dead-letter queue someone actually checks. You need alerting that distinguishes a failed message from a quiet Tuesday. You need idempotency — the guarantee that processing the same event twice doesn't create two orders.
None of that is exotic. All of it is work, and all of it has to be maintained by someone after the project team moves on. When you push every flow through that pipeline, you're paying full freight on data that could have moved overnight with no one noticing.
Start With the Decision, Not the Data
The useful question isn't "how fast can this sync?" It's "what decision does someone make with this data, and how quickly do they make it?"
If a customer is standing on your product page deciding whether to buy, inventory freshness matters in seconds. If your controller is closing the month, the general ledger needs to be right, not instant. If a salesperson is calling a lead, contact ownership matters within minutes. If marketing is building a quarterly cohort report, yesterday's data is fine.
Map the decision first. The latency requirement falls out of it almost automatically, and it's usually looser than anyone assumed.
Four Tiers That Cover Most Businesses
Most mid-market integration landscapes sort cleanly into a handful of buckets:
- Seconds (event-driven): payment authorization, storefront inventory and pricing, credit holds, customer-facing order status, anything that blocks a transaction in progress.
- Minutes (frequent polling or near-real-time events): lead routing, support ticket creation, shipment notifications, CRM-to-ERP account updates.
- Hourly (scheduled jobs): commission calculations, internal dashboards, inventory replenishment signals, partner feeds.
- Nightly (batch): financial posting, reporting warehouses, bulk price list updates, data archiving, reconciliation runs.
Put every integration on your roadmap into one of these tiers before you write a line of code. The exercise takes an afternoon and routinely cuts the number of real-time flows down to a short list.
What Batch Quietly Gives You
Batch processing has an image problem — it sounds like mainframes and green screens. In practice it offers things that streaming architectures have to work hard to replicate.
A batch job has a clear boundary: it started, it processed a known set of records, it finished or it didn't. That makes failure legible. You can rerun it. You can diff the output against the source. You can look at a log and say exactly which 400 records moved last night. With a stream of individual events, reconstructing "what should have happened between 2 and 3 a.m." is a forensic exercise.
Batch also gives you a natural place to validate. Bad data caught in a nightly load is a corrected file. Bad data streamed into your ERP in real time is a cleanup project.
The Hybrid Most Companies Actually Need
The practical answer for most operators is a small number of real-time flows surrounded by scheduled ones, with a reconciliation sweep underneath all of it.
That sweep is the part teams skip. Even well-built event pipelines drift — a webhook times out, an API deprecates a field, a record gets edited directly in one system. A nightly or weekly job that compares record counts and key fields across systems and flags mismatches will catch problems your monitoring never sees. It's unglamorous and it's the difference between discovering a data gap in a report and discovering it in an audit.
Set the cadence to match the stakes. Order and inventory data might warrant a daily check. Customer master data might be fine weekly.
Before You Approve the Build
Ask three questions of every proposed integration: Who acts on this data, and how fast? What happens if it's an hour stale — genuinely, not theoretically? And how will we know when it breaks?
If the answers are vague, the flow doesn't need to be real-time yet. Build it on a schedule, watch how the business uses it, and upgrade the ones that earn it. Tightening a latency budget later is straightforward. Unwinding an over-engineered event pipeline that nobody fully understands is not.
If you're scoping an ERP, CRM, and website that all need to talk to each other — and you'd rather spend the budget where it changes outcomes — we'd be glad to walk through your data flows with you. Reach out and let's map them.