Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Best practices/Let the port own resilience

Let the port own resilience

Delivery fails — endpoints time out, certificates expire, partners go down for maintenance. Handle all of it with send-port configuration: retry counts, backoff intervals, throttling and dead-lettering. Don’t reinvent any of it in a component or map.

The send port already sits at the exact boundary where the outside world can fail, and it already knows how to retry, slow down and set aside. When you let it do that job, every destination inherits the same observable, tunable behaviour for free, and the failure stays where it happened — on the way out — instead of leaking back into the receive transaction.

BUS Send port Retry + backoff Throttle On give-up → dead-letter Destination (on success) Dead-letter store

Hand-rolling this in code is worse on every axis. A retry loop inside a component holds the inbound transaction open, hides its state from tracking, and has to be re-tested for every integration that copies it. The port’s settings are declarative, visible in one place, and consistent across the whole platform. The mechanics of each piece live in the retry, throttling and dead-letter patterns.

Corollary. A component that catches an exception and retries an external call is doing the send port’s job in the wrong place. Let it fail, and let the port decide what happens next.