Your payment service is processing orders. Everything looks fine on the dashboard. Then someone notices that 37 orders from last Tuesday never got fulfilled. The payment was charged. The order was never confirmed. Nobody got notified.
You dig through logs. A database timeout caused the Payment Service to crash mid-processing. The events were retried. They timed out again. And again. And eventually — silently — they disappeared.
This is a DLQ problem. Or rather, the absence of one.
A DLQ is not a failure. It’s a safety net. Messages that can’t be processed go here instead of disappearing — so engineers can find them, fix the cause, and replay.
A Dead Letter Queue is a special queue where messages are sent when they cannot be processed successfully after multiple retry attempts.
Think of it as a quarantine area for problematic messages. The message doesn’t get deleted. It doesn’t silently vanish. It gets parked somewhere visible, where an engineer can inspect it, understand why it failed, fix the root cause, and replay it.
Four properties make a DLQ valuable:
Isolation — bad messages don’t block the healthy ones behind them
Visibility — every failure is inspectable, not just logged
Replayability — fix the bug, then reprocess the failed messages
Alerting — DLQ depth > 100 is your canary in the coal mine
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.