Give failed jobs a place to wait for help — SQS and Dead-letter queues

Your goal

Plan how a queue separates repeatedly failing jobs from healthy work.

Why this matters

One damaged order message keeps failing. You will set a retry boundary, keep the failed message for investigation, and return repaired work without creating duplicates.

Words you will use

A dead-letter queue holds messages that repeatedly fail processing. A redrive policy sets when they move there. Redrive also describes moving them back for another attempt.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Separate a stubborn failure

Most order messages work, but one keeps failing after the worker reads it. The team needs to stop endless attempts and inspect the message.

What should be configured?

A dead-letter queue and a suitable receive-count threshold.

A dead-letter queue isolates repeatedly failed messages according to the source queue’s redrive policy. Choose a threshold that allows reasonable retries before moving work aside for investigation.

Repeated failures have a separate destination.

Work queue → repeated failed receives → dead-letter queue

2. Find the cause before replay

The failed message is now visible in the dead-letter queue. The worker still has the same parsing bug that caused the failure.

What should happen before replay?

Inspect the failure and fix the worker or valid message data.

A replay does not repair the cause of failure. Inspect logs and message details, fix the relevant problem, and test the correction. Protect sensitive message contents while investigating.

The team has addressed the reason the job failed.

Inspect → repair → test → prepare replay

3. Return work safely

The repaired worker can process the message, but earlier attempts may have completed part of the job. The queue should not cause duplicate orders.

What should the replay plan include?

Repeat-safe processing and controlled redrive with monitoring.

Use stable work IDs and check existing results so repeated processing is safe. Return messages at a rate the workers can handle, then monitor failures and backlog to confirm the fix.

Replayed work can complete without multiplying side effects.

Controlled redrive → repeat-safe worker → observed result

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.