A dead-letter queue needs a recovery decision

Not every failed message should run again

One message failed because a provider was unavailable. Another contains an unsupported schema. A third already triggered an external action before the worker lost its response. Sending all three back through the same path is unlikely to be safe.

Record what is known about each failure and the operation it represents. A dead-letter queue is a holding area for unresolved work, not a substitute for an application outcome ledger.

Keep transport identity and business identity distinct. A redrive mechanism can assign new transport metadata, while the operation still needs its original identity to prevent duplicate effects.

Classify before replay

Separate transient dependency failures, invalid input, incompatible contracts, obsolete work and unknown effects. These categories lead to different actions.

A transient failure may be retryable after the dependency recovers. Invalid input needs correction or rejection. An unknown external effect needs reconciliation. An obsolete command may need a recorded decision not to execute it.

Check ordering and current state

A message delayed for days may no longer represent a valid action. An old address update can overwrite a newer correction, and an expired reservation command can create work the user no longer wants.

Use the domain's revision or transition policy when processing recovered messages. Queue order alone cannot establish business validity, especially when replayed messages mix with new traffic.

Amazon SQS documents that redriven messages can interleave with newly produced work. Its redrive also assigns new message metadata, reinforcing the need to preserve business identity in the application contract.

Bound the recovery load

Replay at a measured rate that the consumer and downstream services can sustain. A large redrive can turn a resolved provider outage into a fresh overload.

Start with a representative sample and verify effects before increasing scope. Keep a way to stop further movement and understand what has already reached the destination.

Treat retention as a deadline

Know when messages and related diagnostic evidence expire under the actual queue type and platform. A dashboard's displayed age may not describe the complete business-operation age.

Assign an owner and review cadence before unresolved work disappears. The recovery design is complete when failed operations reach known outcomes, not merely when the dead-letter queue becomes empty.