How current must integration data be?

Name the decision behind the update

“Everything in real time” leaves unanswered which delay is acceptable for which task. Stock may affect a sales commitment. Editorial copy may wait until an agreed time. The required freshness follows from that use; only then can the transfer method be chosen sensibly.

In asynchronous workflows, systems may temporarily show different states. Microsoft describes this consequence of event-driven architecture. A promptly triggered event does not remove queues or target processing time.

Example: two fields, different consequences

The following table is fictional planning, not a measurement or a general recommendation for update intervals.

Even frequent stock updates alone cannot prevent simultaneous sales of the same last unit. The ordering process needs a reliable availability check and reservation rule for that. Conversely, a description may contain safety-related or contractually important information. Its delay cannot then be assumed harmless.

Agree on a target, measurement point and fallback

For each data group, define which confirmed source state starts the clock and when the change must actually be usable in the target. Successful dispatch to an interface is an earlier measurement point. Also specify who handles overruns and what is displayed when freshness is unknown, or what must be checked before a commitment.

Microsoft presents several integration patterns, including batch processing. A scheduled batch may fit tolerable waiting times. Events may help with tight timing needs but bring their own operational responsibilities. Evaluate the choice using delayed and rejected changes before promising a freshness level.

Sources

• Microsoft: Event-driven architecture

• Microsoft: Data integration patterns