Design integrations for retries and duplicate events

An integration is more than a successful request between two systems. Networks fail, responses arrive late, and an event may be delivered more than once. Designing for these conditions makes the difference between a connection that works in a demonstration and a workflow that can be operated reliably.

Define the meaning of success

Decide whether a successful response means a record was accepted, validated, queued, or fully applied. Document the data contract, including required fields, identifiers, and permitted changes. Distinguish errors that should be retried from records that need correction. Retrying an invalid request indefinitely does not make it valid.

Make repeated work safe

Use a stable event or business identifier to recognize work already processed. Consider what happens if the receiving system applies a change but its response never reaches the sender. A retry should not create a second order or repeat a consequential action. Store enough processing state to distinguish a new event from another delivery of an existing one.

Provide a visible recovery path

Log a useful correlation identifier without exposing sensitive payloads unnecessarily. Define retry limits and a review queue for unresolved failures. Operators need to see what happened, correct the cause, and replay work safely. Reconciliation checks can catch gaps that individual request logs do not reveal.

Walk through an ambiguous outcome

Imagine a service that accepts an order and then sends a confirmation to another system. The receiver stores the confirmation, but the sender loses its connection before receiving the response. From the sender's perspective, delivery is uncertain. Simply repeating the action could produce a second confirmation; refusing to retry could leave a genuinely failed delivery unresolved.

Give the business operation a stable identity that survives retries. Decide where the receiver records that identity and what response it returns when the same operation arrives again. This is a workflow design question as much as a transport question. A repeated notification, a duplicate financial transaction, and a repeated inventory adjustment have different consequences.

Make the state visible to support

Use operational states that distinguish waiting, completed, and requiring intervention. Store enough context to correlate the sender's record with the receiver's result. A support operator should be able to investigate one operation without guessing from timestamps or replaying an entire batch. Restrict access to sensitive payloads and prefer identifiers in routine logs where they are sufficient.

Define a deliberate end to automatic retries. Some failures can resolve with time, while invalid data may require a correction. Record who handles that correction, how the operation resumes, and how the team confirms that the final business state is correct. A retry loop without an owner can hide a growing backlog of unfinished work.

Try the unhappy paths in a rehearsal

• Send the same operation twice and inspect the final business state.
• Interrupt the connection after the receiver begins processing.
• Deliver an older event after a newer one and examine the ordering rule.
• Make the receiver unavailable and inspect the queue and recovery behavior.
• Submit invalid data and follow the correction path as a support operator.

The expected answer should be written before running each exercise. A test that merely reports that the request returned something does not establish that the two systems agree. Verify the records and visible outcomes on both sides, then keep those scenarios as part of future integration changes.

A practical next step

Write three integration tests: a timeout after the destination accepted the change, delivery of the same event twice, and an invalid record followed by a corrected one. Use the results to improve the processing contract.