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.
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.