Normalize onto the bus
The receive side’s job is to turn whatever arrived into one clean, canonical message and publish it. Delivery is the send port’s job. Normalize once, and any number of subscribers can consume it — without you touching the feed again.
A pipeline component can technically do anything: call a database, post to an API, finish the whole integration in one place. It is the single most tempting shortcut in the product, and it is almost always the wrong one. The moment a component delivers, the feed is welded to one destination and the bus stops doing its job.
Instead, draw a hard line. The receive pipeline parses, validates and maps the inbound payload into a canonical message, then publishes it to the bus. Subscriptions decide who gets it. Each send port owns its own delivery, with its own retry, backoff and dead-lettering. The producer never learns who is listening.
The payoff is concrete. A second consumer is a new subscription, not a code change. Every message is visible on the bus, so you get tracking, audit and a natural resume/replay point. A slow or broken destination is the send port’s problem, not the receive transaction’s — it cannot poison the inbound feed or block throughput.
This is the foundation the rest of these practices build on: route through canonical, map at the edges, and keep components out of the delivery business are all corollaries of this one rule.