Problem
Failed messages block queue, cause retry storms, and are lost if not captured. Need isolation for forensic analysis.
resilienceestablished · medium operational burden
Dead Letter Queue (DLQ)
Also known as: dlq, dead-letter, poison-message
Intent
Capture messages that fail processing repeatedly for later inspection and replay, preventing pipeline blockage.
Forces
- •Some messages are fundamentally unprocessable (bad schema, missing data)
- •Retries waste resources and block valid messages
- •Failed messages need investigation, not deletion
- •DLQ must not grow unbounded
Solution
✓ When to Use
- •Any async message processing system
- •Message failures are expected (bad data, transient bugs)
- •Need visibility into failure patterns
✗ When Not to Use
- •Synchronous request-response (no queue)
- •Fire-and-forget where loss is acceptable
- •Team not ready for DLQ operational process
Pros
- +Prevents pipeline blockage: bad messages isolated
- +Preserves failed messages for debugging
- +Enables replay after fix
- +Visibility: DLQ depth = health signal
Cons
- −DLQ can grow unbounded (retention policy needed)
- −Replay complexity: ordering, duplicates, side effects
- −Operational: someone must triage DLQ regularly
- −Root cause often in producer (schema, validation)
Cost Profile
Infrastructure
Low — extra queue/topic
Operational
Medium — triage, replay, retention
Cognitive
Low — standard pattern
Failure Modes
DLQ ignored → grows until OOM/quota
Replay causes same failure → infinite loop
Replay out of order → state corruption
DLQ monitoring missing → silent accumulation
Poison message not detected → retries forever
Real-World Examples
Alternatives
- retry-only
- circuit-breaker
- poison-pill
- message-filter
Related Patterns
- retry-with-backoff
- circuit-breaker
- idempotency-key
- outbox-pattern
- poison-message
Competency Domains
reliability opsdistribution communicationdata stateeconomics evolution