“We need it in real time” sounds like a clear requirement until someone asks how much time may actually pass between a sale and its arrival in the operations system. Seconds? Ten minutes? Before the next dispatch run? The answer changes the architecture, and agreeing on it can take more thought than connecting the applications.
Start there when choosing between events and scheduled processing. Checking the CRM every ten minutes and receiving a notification when a sale is confirmed can each meet a different, legitimate need. The interesting questions come afterwards: how will you know the work finished, what happens if a notification is missing, and how will you prevent a retry from creating the order twice?
What an event is telling you
An event describes a fact: an order confirmed, a document received or a request closed. Consumers react according to their own responsibilities. A scheduled process runs according to a timetable and checks which work is available. Microsoft's description of event-driven architecture separates producers, channels and consumers. This supports independently designed components while making delivery and processing explicit architectural concerns.
A webhook is one way to notify another system through an HTTP request. By itself, it does not guarantee durable storage, retries or successful processing. Those properties depend on the provider's contract and the receiving architecture. Likewise, scheduling does not automatically ensure completeness. A badly designed query can skip records or retrieve them repeatedly. Both approaches require a reliable definition of progress.
Ask how much delay is acceptable and what happens when that limit is exceeded. “Real time” expresses an aspiration without defining an operating objective. Convert it into a measurable interval between the original event and the required result. When updates can wait for hours, scheduled batches may offer a simpler solution. When value declines with every minute, notifications can reduce waiting. Still include the processing time of consumers and their dependencies.
Compare empty queries as well. Frequent polling can consume capacity even when nothing has changed. Balance that cost against the effort of operating a dependable event channel. The right comparison includes failure recovery, not just normal-day speed. A fast integration that silently misses requests may be less useful than a slower one with clear completeness checks.
Receiving the message is only the beginning
When a notification arrives, validate authenticity, structure and size. Decide when to acknowledge it. Responding before the work is durably recorded creates a window in which failure can lose the request.
Processing everything before replying creates a different risk: slow operations may exceed the sender's timeout. One common design records the input safely, acknowledges receipt and performs the work afterwards with visible status. The contract must explain what acknowledgement means. “Received” and “completed” are different states. Confusing them can leave both systems apparently healthy while a customer-facing operation remains unfinished.
Make status accessible to the component or person responsible for the complete business case, rather than hiding it inside a transport log.
Twice, or in the wrong order
Some delivery mechanisms can send the same message more than once. A consumer should check whether the event identifier or associated business operation has already been handled. This matters especially when creating records or sending communications. Do not assume a global arrival order. A later update may arrive before an earlier one. Use source versions where available and define how to reject obsolete changes or retrieve the current authoritative state.
Avoid promising exactly-once business effects without verifying every dependency. Deduplicating the incoming event does not automatically prevent a repeated external call after an uncertain response. For consequential actions, define how to investigate uncertainty before retrying. That decision belongs in the process design rather than being left to an operator during an incident.
Three teams and an unfinished order
Imagine a sale that must reach operations, invoicing and sales follow-up. The producer records the order and emits an identifiable event; each consumer performs its own task without waiting for all the others. The diagram looks appealing. The difficulty arrives when operations has already reserved work but invoicing has been unavailable for twenty minutes.
Repeating the whole journey would be poor recovery if it reserved the same work again. In this hypothetical design, invoicing remains pending while confirmed actions retain their state. Someone must be able to see that the order is only partly processed, how long it has been waiting and what that means for the next activity. Business rules may call for a notification or for a later step to be put on hold.
Connecting consumers does not automatically create that complete view. Decide which system presents it and who takes responsibility when a stage misses its deadline. Otherwise, every team can own a technically correct component while the customer still has no useful explanation of what happened to the order.
Why a periodic check still has a place
Notifications can be missed because of configuration errors, outages or limited delivery guarantees. A scheduled reconciliation process can compare records and detect gaps. This does not mean running the same work twice without coordination. Both routes should use the same identifiers and duplication controls. Reconciliation verifies what happened and deliberately recovers missing work.
Combining prompt notifications with periodic checks can be useful when responsiveness and completeness both matter. Define how to distinguish ordinary processing delay from a genuinely missing case. Reconciliation itself should produce an auditable result: which records were checked, which differed and which corrective actions were taken.
A contract consumers can understand
An event needs stable meaning. Document what it represents, its identifier, when it is emitted and required fields. Avoid consumers depending on internal details that producers may change without warning.
Choose whether the event carries sufficient data or references that consumers resolve later. Embedded data reduces follow-up queries but increases duplication and transported information. References create an availability dependency and may retrieve a later state. Make that choice according to sensitivity, size, historical reconstruction and consistency needs. Test compatibility before changing the schema.
What to watch when work runs late
When operating the integration, follow the delay from the originating system through to the business result. Watch the age of pending work, failures, repeated deliveries and cases awaiting intervention. A healthy intermediary tells you little about whether an invoicing consumer has completed its job. Retry limits and a destination for unprocessable messages give operators somewhere to look; enough preserved context lets them correct and replay work without duplicating completed actions.
Test outages, duplicate and reordered inputs, traffic bursts, and consumers catching up after downtime. Then return to that original request for “real time”. If the outcome can wait for the next batch and volume permits it, scheduling may be sufficient. If minutes affect the value of the response, or several consumers need to react independently, events may justify the extra operating work.
Bring the required deadline and an example of missing it to DigitalCube. An order that never reached invoicing is easier to reason about than an abstract ambition for immediacy. The architecture should help explain where that order is, including on the day one component stops responding.