The bus favours delivering twice over losing once, the right trade, but it means downstream logic must tolerate repeats. A retried send, a replayed batch, a partner that re-sends on timeout all produce the same message again. If processing it twice creates a duplicate order or a double charge, the integration is fragile by construction.

The fix is to dedupe on a stable business key, an order number, an EDI control number, a source record id, surfaced as a promotion so it is visible for routing and checks. A receive-side guard records keys it has already seen and no-ops repeats. A native dedupe feature is under development; until it lands, the guard lives in the consumer, typically the stored procedure or destination system that processes the message. This practice is the mandate to apply it by default, not as an afterthought.