Learn the vocabulary of isolating a persistently failing message instead of retrying it forever.
0 / 5 completed
1 / 5
At standup, a dev mentions a separate queue where a message that repeatedly fails processing gets routed after exceeding a retry limit, instead of being retried forever or silently dropped. What is this separate queue called?
A dead-letter queue, or DLQ, is a separate queue where a message that repeatedly fails processing gets routed after exceeding a retry limit, rather than being retried forever or silently dropped and lost. Retrying a failing message indefinitely risks it blocking the processing of every other message queued behind it. This separate queue is what isolates a persistently failing message while still preserving it for later inspection.
2 / 5
During a design review, the team wants to configure exactly how many times a message can fail before it's automatically moved to the dead-letter queue. Which capability supports this?
A max-retry count, or redrive policy, configures exactly how many times a message can fail before it's automatically moved to the dead-letter queue, rather than being retried an arbitrary or unlimited number of times. Moving every message to the DLQ on its very first attempt would treat a normal, transient failure the same as a genuinely broken, unprocessable message. This configurable retry count is what lets a system distinguish a message worth retrying from one that's truly stuck.
3 / 5
In a code review, a dev notices the team monitors and alerts on the dead-letter queue's depth, so a systemic processing failure affecting many messages is noticed quickly rather than discovered much later. What does this represent?
Monitoring dead-letter queue depth catches a systemic processing failure affecting many messages quickly, since a sudden spike in DLQ depth signals something has gone broadly wrong rather than a single, isolated failure. Letting the queue accumulate with no monitoring risks a widespread failure going unnoticed for a long time. This monitoring turns a dead-letter queue from a passive holding area into an active early-warning signal for the team.
4 / 5
An incident report shows a single poison-pill message was retried indefinitely, blocking the processing of every other message queued behind it, because no dead-letter queue or max-retry policy had been configured. What practice would prevent this?
Configuring a max-retry policy that routes a persistently failing message to a dead-letter queue isolates that poison-pill message so it stops blocking every other message behind it. Retrying it indefinitely with no such policy is exactly what causes the queue-wide blockage this incident describes. This configuration is a baseline safeguard for any message-processing system where a single bad message shouldn't be able to stall the entire queue.
5 / 5
During a PR review, a teammate asks why the team routes a persistently failing message to a dead-letter queue instead of either retrying it forever or dropping it silently. What is the reasoning?
A dead-letter queue isolates a poison message so it doesn't block the rest of the queue's processing, while still preserving that message for later inspection rather than losing it outright, unlike simply dropping it silently. Retrying it forever instead risks it stalling every other message queued behind it. The tradeoff is the ongoing operational responsibility of monitoring and eventually addressing whatever ends up accumulating in the dead-letter queue.