The successful request is only one case
An integration demonstration often ends when a record appears in the destination system. That proves connectivity, but not operational reliability. Ask what happens if the destination saves the record but the response is lost. The sender may retry, producing a duplicate unless the workflow has a stable way to recognize the same operation.
Give an operation an identity
Use a stable identifier for the business event and preserve it across retries. For example, an order-confirmed event should refer to the same order and event identity each time it is delivered. The receiving system needs to know whether it has already applied the side effect. A random new identifier for every retry defeats that purpose. Document how long duplicate detection must remain effective for the business process.
Decide which system owns each field
Two-way synchronization is not a substitute for a data-ownership model. If both systems can change a customer address, decide how conflicts are resolved and which changes are allowed to flow back. Consider timestamps carefully: a later timestamp does not always represent the more authoritative business decision. Sometimes the correct response is an exception for a person to review.
Separate retryable and permanent failures
A temporary service outage may justify a bounded retry. An invalid account identifier needs correction, not endless repetition. Record enough context for an operator to distinguish these cases without logging sensitive payloads unnecessarily. The recovery interface should show what failed, what action is possible and whether repeating it can create another side effect.
Reconcile the business result
Transport success does not prove that the business records agree. A scheduled reconciliation can compare expected orders with received orders and identify missing or contradictory states. Choose the comparison around the actual business invariant, such as one fulfilment request per paid order, rather than merely counting HTTP responses.
A small acceptance matrix
Before release, test the same event twice, a delayed event, a timeout after a possible write, an invalid record and an unavailable destination. Include a recovery exercise: can the responsible person identify the failed operation and resolve it without direct database edits? These tests make the integration easier to maintain because its difficult behaviour has been designed rather than left to chance.