“We need real time” is one of the most common requirements in integration projects. In reality, only a small portion of flows truly need live data. The rest can be event driven or batch, which are usually simpler, cheaper, and more reliable. This guide gives you a practical way to decide which is which.
What We Mean by Real Time and Batch
Before arguing about options, it helps to define terms in plain language.
- Real time: A user action in one system triggers an immediate call to another system, and the response affects what the user sees right away. For example, checking credit in Business Central while a customer service rep is on the phone.
- Near real time / event driven: Events are pushed quickly between systems, usually within seconds or minutes, but not blocking a user screen. For example, sending a new quote from the website to Business Central via an intake API as soon as it is submitted.
- Batch: Data moves on a schedule, such as every 5, 15, or 60 minutes, or overnight. For example, syncing inventory snapshots from Business Central to the website every hour.
Most of the time, the real question is not “real time or batch” but “what needs to be blocking and what can be asynchronous.”
When You Really Need Real Time
There are legitimate cases where real time integration is worth the complexity.
- Decisions with immediate financial impact: Credit checks, payment authorization, or limit checks that must be correct before you proceed.
- Scarce resources: Allocating a limited asset such as a specific rental unit, seat, or time slot that could be double booked.
- Compliance or policy enforcement: Rules that must be applied before a transaction is accepted, not after the fact.
- High touch interactions: Scenarios where a person is on the phone or chat and must give a firm answer based on ERP data.
In those cases, the user experience and risk profile justify calling an ERP like Business Central in the critical path.
When Batch or Event Driven Is Better
For many other flows, insisting on real time just adds cost and fragility without real business benefit.
- Reporting and dashboards: Boards and managers almost never need second by second updates.
- Marketing and analytics: Lead scoring, campaign attribution, and trends work fine on a delay of minutes or hours.
- Non critical status updates: Updating a customer portal with “in progress” versus “completed” typically does not need millisecond precision.
- Reference data feeds: Sharing product catalogs, rate tables, or location lists can be scheduled.
In these areas, batch or event driven integrations are simpler to operate and much more tolerant of outages or slowdowns.
How Real Time Impacts Reliability and Cost
Real time sounds good on paper, but it couples systems tightly.
- If Business Central is slow or unavailable, your website or CRM may slow down or fail.
- Every user action becomes subject to network issues, rate limits, and transient errors.
- Scaling becomes harder, because peak traffic on the website drives peak load on the ERP.
- Debugging requires you to look across more systems in the critical path.
Batch and event driven approaches let you buffer, retry, and shape load, which usually leads to higher overall reliability.
Designing for Perceived Real Time
Often, users do not need true real time. They just need the experience to feel responsive.
- Show immediate confirmation of form submissions while processing ERP updates in the background.
- Use progress indicators and clear messaging instead of blocking spinners.
- Refresh parts of the UI when updates arrive, without making the user wait on an ERP call.
- Provide realistic timing expectations, such as “You will see this in your portal within a few minutes.”
This lets you keep the user experience snappy while keeping ERP work asynchronous and controlled.
Real Time vs Batch for Website and Business Central
For a typical WordPress plus Business Central stack, a pragmatic split might look like this:
- Real time or near real time: Credit checks, contract eligibility checks, or pricing calls invoked by internal staff tools.
- Event driven: Web quote submissions, contact requests, and self service changes flowing into Business Central staging tables.
- Batch: Nightly or hourly updates of product data, pricing snapshots, inventory availability summaries, and analytics exports.
The key is to keep the public website mostly decoupled from ERP performance, while still respecting Business Central as the system of record.
Error Handling, Retries, and Back Pressure
Error handling is one of the biggest differences between real time and batch approaches.
- In real time: You must decide immediately what to tell the user if the ERP is slow or returns an error. That usually means fallbacks or graceful degradation.
- In batch or event driven: You can queue messages, retry with back off, and alert someone if thresholds are exceeded.
- For both: You need correlation IDs and logs so you can trace a specific transaction end to end.
Thinking about error paths early often reveals that some flows are better off asynchronous.
A Simple Decision Checklist
When someone says “this needs to be real time,” run through this checklist:
- If this took 5 minutes instead of 5 seconds, would anything truly break.
- Is a person actually waiting on the other side of the screen for a final answer from the ERP.
- Will errors be easy or hard to recover from if something goes wrong in the middle.
- Does this require locking or allocating a scarce resource in a way that must be coordinated centrally.
- How often will this run at peak times, and can the ERP realistically handle that load.
If the honest answers do not strongly justify real time, consider an event driven or batch pattern instead.
How Elephas Helps You Make the Call
Choosing between real time and batch is not just a technical decision. It affects user experience, operations, and support.
- We map your key flows across website, Business Central, and other systems.
- We help you categorize each integration by risk, volume, and timing sensitivity.
- We propose architectures that use real time only where it pays off and batch or event driven patterns everywhere else.
- We implement staging tables, logging, and monitoring so you can see how integrations behave in practice.
The result is an integration landscape that feels fast where it matters, stays robust under load, and does not require heroics every time one system has a bad day.
