Dead letter recovery
Deploy the compatible consumer before replaying old messages
Failed work may use an earlier contract or expose the exact defect being fixed. Verify the new consumer against that history before releasing the backlog.
In this article
Inventory the retained contracts
Identify message versions and failure categories in the selected backlog. Use safe samples that preserve the relevant structure without unnecessarily copying sensitive content.
Keep original operation identity and acceptance time available. A new transport record should not erase the history needed for duplicate and staleness checks.
Determine which messages are still valid business work and which require a separate decision.
Test the new consumer on representative failures
Run old payloads through the actual deserialisation and business logic. Check the resulting state, not only whether parsing succeeds.
Include a message whose effect already occurred before the old worker failed. The replacement must recognise or reconcile that state safely.
For an illustrative contract change, an old missing field may need an explicit unknown value rather than a default that invents historical information.
Suppose version one omitted a delivery-service field that version two requires. Setting every old message to the new default can change a customer's intended dispatch. A translation should derive the value from trusted historical evidence when available, or hold the operation for review when it is not.
Keep a fixture for both cases. Compatibility means processing the old meaning correctly, not merely constructing an object that passes the new schema validator.
Release processing before the backlog
Deploy the compatible consumer and verify current traffic. Then enable a bounded replay cohort.
Avoid changing schema interpretation and replaying the entire backlog in one unobservable step. If results are wrong, the team needs a clear point to stop further impact.
Keep rollback compatibility with any data the new consumer writes during recovery.
Expand based on outcomes
Measure completed, repeated-failure and held operations from the sample. Increase replay only when the intended result is demonstrated and downstream capacity remains suitable.
Record transformed or deliberately closed messages with their reasons. Do not rewrite history silently to make every item appear successful.
Retire old compatibility code only after retained and recovery-relevant messages no longer require it, or a tested translation path exists. The rollout is complete when both current work and the selected history can be processed under a maintained contract.
Primary sources
Amazon SQS: redrive behaviourReferences checked 11 September 2026.