The happy path is only half the integration.

An integration can work perfectly in a demonstration and still cause trouble in daily use. Real systems send duplicates, respond slowly and become temporarily unavailable.

Give each operation an identity

If a request is sent twice, should the outcome happen twice? For many business operations, the answer is no. Track a stable operation identifier and use the destination system’s idempotency support where it exists.

The exact design depends on the service, but the intent is simple: repeat delivery should not accidentally create a second invoice, booking or customer record.

Retry deliberately

A temporary connection failure may be worth retrying. Invalid input usually needs correction. Distinguish these cases, limit attempts and wait between retries. Be careful with ambiguous timeouts: the destination may have completed the operation even though the response was lost.

validate(event)
if already_processed(event.id):
    return previous_result(event.id)

result = deliver_with_bounded_retries(event)
record_outcome(event.id, result)
alert_if_action_needed(result)

This sketch is not a complete concurrency-safe implementation. In production, duplicate checks and result recording need a transactional or otherwise race-safe design suited to the destination.

Make the work observable

Record enough information to answer what happened, when it happened and what needs attention. Keep secrets and unnecessary personal information out of logs. A useful error message points to a recoverable action rather than displaying an internal stack trace.

Test the awkward cases

Send a duplicate. Remove a required field. Simulate a timeout. Retry after a partial failure. Check what an operator sees and whether the system can be brought back to a known state.

Reliability comes from designing the inconvenient paths alongside the convenient one. That work is less visible than a polished demonstration, but it matters more once real people depend on the system.