Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Patterns/Advanced & future/Message-history & replay

Message-history & replay

Things break downstream after a message has already moved. Replay is how you recover: re-publish the affected messages from the bus’s durable record and let them run again, no re-extraction from the source, no manual reconstruction.

Replay is the concrete capability behind design for replay. Because every canonical message is persisted and tracked when published, the bus holds a history you can draw from. Fix the bad map, register the missing subscription, or bring the endpoint back, then select the affected messages, from the archive or the dead-letter store, and re-publish them.

message history Replay select & re-publish BUS re-processed normal flow, as if new

Replay is only safe if reprocessing is safe, which is why idempotency is a standing rule: a replayed message must not double-apply. Done right, recovering from an outage or a bad deployment is routine (select the window, replay, done) and it is the same machinery that lets event sourcing rebuild state from history.

Replay needs its referenced data to still exist. A claim-checked payload or an enrichment source must still be available at replay time, align retention so a replay weeks later resolves, or fails loudly rather than silently producing a half message.