Skip to content
Art2link ESB HomeDocumentationBlogContact
Updated May 5, 2026
Best practices/Subscribe, don’t hardcode

Subscribe, don’t hardcode

A producer publishes to the bus and stops there. Who receives the message is decided by subscriptions on the consuming side, so adding the next destination is a configuration change, not an edit to the thing that produced the message.

The whole value of the bus is that producers and consumers do not know about each other. A receive port publishes a canonical message; each send port declares a subscription, usually a filter over a promoted variable, and the bus delivers a copy to everyone whose filter matches. The producer’s configuration never names a destination.

Producer (receive port) BUS Send port, ERP filter: type = Order Send port, Lake filter: type = Order Send port, Partner filter: type = Order + new consumer = new subscription producer is never touched

The anti-pattern is any place where the list of destinations is written into the producer: a component that loops over hard-coded endpoints, or a map that branches on “if partner X also send to Y.” Both turn a routine onboarding into a redeploy and re-couple the very things the bus exists to separate. If routing depends on content, express it as a content-based router, still subscriptions, just smarter filters.

Rule of thumb. Onboarding a new destination should never reopen the producer. If it does, the routing decision is living in the wrong place.