Idempotent by design
In a system with retries, store-and-forward and replay, the same message will be processed more than once. Design every receiver so a duplicate changes nothing. Exactly-once is a fantasy; at-least-once plus idempotency is the real guarantee.
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 — promoted to a variable so it is visible for routing and checks. A receive-side guard records keys it has already seen and no-ops repeats. The idempotent receiver pattern shows the concrete build; this practice is the mandate to apply it by default, not as an afterthought.