Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Patterns/Resilience & operational/Store-and-forward

Store-and-forward

When a destination is down, the messages bound for it need not fail. A brief outage is ridden out by the send port’s own retries; a longer one is parked and re-submitted once the destination returns.

Store-and-forward is the operational face of guaranteed delivery, and in Art2link you compose it from two tiers rather than flip a single switch. For a brief outage the send adapter’s retries — a Retries count and a Retry interval — ride it out: the message stays on the durable bus and delivers the moment the endpoint answers, with no manual step.

For an outage longer than that retry budget the adapter eventually gives up, so enable Exception on the port. The exhausted message re-publishes under an exception message type and is parked in a holding store you control — commonly a database table. A separate flow re-submits the held messages once the destination is confirmed back, on a schedule (a Scheduler-driven flow) or by operator action; there is no automatic re-drain beyond the retry budget. Ordering is not something the platform guarantees here — if sequence matters, read the store in order on the way out, or pair with the resequencer.

bus — durable store held while offline Destination — offline Destination — back online forwarded on recovery nothing lost

It is the delivery-side twin of the durable subscriber and the mechanism a circuit breaker leans on while it is open. Together they make routine downtime — theirs or yours — something the platform simply rides out.

Watch the backlog, not just the outage. A long outage builds a large store and then a flood on recovery — pair store-and-forward with throttling so the catch-up does not overwhelm the destination the instant it returns.