What happens when an integration fails or sends the same record twice?
Plan integration monitoring, controlled retries, duplicate prevention and recovery responsibilities using verified technical sources.
An integration needs to account for more than a clear success or failure.
Consider an illustrative invoice transfer: the accounting application creates the invoice, but the connection drops before the sending system receives confirmation. From the sender’s perspective, the outcome is uncertain.
Sending the request again without checking could repeat work that already succeeded.
Make the outcome visible
For each transfer, define how someone can distinguish work that is waiting, completed, rejected or awaiting investigation.
Useful operational information can include the source record identifier, destination identifier, attempt time and a meaningful failure category. Decide which details belong in logs and which should be omitted because they contain sensitive information.
The important business question is whether the intended record or action reached its destination.
Distinguish temporary failures from records needing correction
A temporary service interruption may justify a controlled retry. A missing required field may need a person to correct the record first.
Microsoft’s Retry pattern recommends choosing a response based on the failure: cancel an operation unlikely to succeed when repeated, or use an appropriate retry strategy for a temporary fault. It also highlights the need to consider whether repeating an operation could create unintended effects. Microsoft’s Retry pattern.
Agree retry limits and escalation behaviour. Repeated attempts should not leave an unresolved task invisible indefinitely.
Keep a record of work already completed
Use the identifiers and mechanisms supported by the applications involved.
For example, Xero documents idempotency keys for supported write requests. Qualifying repeated requests can receive the original cached response rather than processing the operation again. The keys expire, so the integration must account for that limit when resolving uncertain outcomes. Xero’s idempotent-request guidance.
A proposed design should also define how it records the relationship between a source item and its destination record. That supports reconciliation after the original request window has passed.
Give failed work an owner
Decide:
- Who receives an alert?
- Who can investigate the affected records?
- Who can approve a retry or correction?
- How can processing be paused?
- How will completed recovery work be recorded?
Provide a way to review unresolved items. An error message without a responsible person or next action is an incomplete operating process.
A documented example of background processing
Sangfroid’s published architecture includes Cloud Tasks and a dedicated email worker, separating background email processing from interactive application requests.
That establishes the components used in the platform. It does not establish a particular retry configuration or a guarantee that a message can never be processed twice. Explore Sangfroid’s application architecture.
Test uncertain outcomes deliberately
Before release, test a repeated source event, a timeout after processing, an unavailable destination and a record that cannot pass validation.
For each case, check the resulting business records as well as the technical response. The goal is an integration whose outcomes can be understood and whose exceptions can be recovered under an agreed process.