# Batch or real-time sync? Start with acceptable delay.

> Choose a synchronization approach around the age of information your workflow can tolerate and how staff handle delayed updates.

- Published: Sep 25, 2026
- Topic: Software decisions
- Author: RDR Digital
- Original: https://rdr.digital/blog/batch-or-real-time-sync

A daily management report and a customer checking available stock have different needs. Asking every connection to be “real-time” avoids the more useful conversation: how old can this information be before someone makes the wrong decision?

Write that tolerance into the brief. Then choose an approach that can meet it under the conditions your business actually faces.

## Describe the decision that uses the data

For each connection, name the person or process waiting for the update. Record the consequence of a delay and what should happen when the information is older than expected.

The following examples are questions to resolve, not universal timing recommendations.

| Workflow                | Question that determines the requirement                           |
| ----------------------- | ------------------------------------------------------------------ |
| Daily sales summary     | Must late corrections appear before a particular reporting cutoff? |
| Available stock         | Will an order reserve stock, or is the display only an indication? |
| Shipment notification   | How long may a customer wait after dispatch is confirmed?          |
| Customer address change | Which open orders should receive the new address?                  |

An agreed maximum data age is more meaningful than a promise to “sync frequently.” Include the time from the original business change to the receiving system's usable update, not just the time taken to send a message.

## Understand the two approaches

In a batch approach, records are processed together at an agreed interval or trigger. In an event-driven approach, a change produces a notification that another part of the system processes.

Microsoft's [event-driven architecture guidance](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven) explains that asynchronous consumers can temporarily hold different views of the data. It also identifies concerns such as duplicate processing and event ordering. Event-driven does not automatically mean that every connected screen changes at the same instant.

Ask the technical team to show where waiting can occur: before a job starts, in a queue, while a third party is unavailable, or while an update is rejected for missing information.

## Use different approaches for different work

A business does not have to choose one method for every record. For an illustrative retailer, a stock-change notification could prompt an update during trading hours, while a separate reconciliation checks for differences across systems.

That combination still needs clear ownership. Establish which process may correct a mismatch and whether a correction could overwrite a newer legitimate change. Ask for a test that demonstrates the intended behavior.

Consider the connection's operating constraints as well: the receiving platform's supported APIs, request limits, expected volume, and the effort needed to run and monitor the solution. Confirm these against the actual services rather than assuming a connector supports your preferred schedule.

## Make delayed information visible

Define how staff will distinguish current, pending, failed, and unknown states. A timestamp showing the last successful update can be useful, but ask what that timestamp proves. One successful record does not establish that every record is current.

Decide whether the workflow should continue, pause, or request a manual check when freshness falls outside the agreed tolerance. Different decisions may deserve different behavior.

## Test the delay you are trying to avoid

Rehearse a missed batch, a delayed event, a duplicate notification, and a receiving system that returns after an interruption. Measure how long the business view takes to become correct again.

Record the observed result and the conditions of the test. If it misses the requirement, revisit the architecture or the workflow rather than changing the label.

For the operational plan behind these tests, read [what to prepare when an integration fails](https://rdr.digital/blog/when-an-integration-fails).

## Sources

- [Microsoft Azure Architecture Center: Event-driven architecture](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven)