Topic 10.15
Dead Letter Queue (DLQ)
In one line
The parking lot for poison messages: retried N times, failed, and now visible to a human.
Think of it like this
A 'return to sender' bin at a post office for letters that couldn't be delivered after several attempts, so they don't just get lost — someone can open the bin later and investigate what went wrong.
Key ideas
- 01
Poison message: a payload that always fails processing (corrupt, schema drift, semantics violation).
- 02
Policy: N retries → DLQ with original headers + failure reason attached.
- 03
Why DLQ and not drop: an audit-able 'saved work' that ops can replay AFTER the fix (schema change, data repair).
- 04
DLQ monitoring is mandatory: alert on DLQ depth — a silently growing DLQ is a deferred outage.
- 05
Replays: fix the consumer's handling, then re-push DLQ entries (Kafka: seek offsets; Rabbit: republish).
- 06
Interview: 'poison messages get 3 retries then a dead letter — that's my safety net' — say it before the interviewer asks.
Java / Spring map
- →
Spring Kafka: @DltHandler (Spring Boot dead-letter pattern); @RetryableTopic creates retry/DLT topics.
Code & diagrams
Explain without notes
Why does a poison-message system NEED human visibility — what silently breaks if the DLQ has no alert?
Practice
Lay out topic layout: main, retry-1/2, DLQ, and the alert rule per backlog depth.
Trade-offs
- ↔
DLQ protects the pipeline but removes the pressure to fix the root cause — alert on it or it rots.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I include a DLQ + alert in every async pipeline I design.