What is a dead-letter queue and when should you use one?
Assesses fundamental understanding of Message Queues & Streaming conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
A dead-letter queue (DLQ) is a separate queue that receives messages a consumer cannot process after exhausting retries. It prevents one poison message from blocking a partition or queue forever and preserves the payload for diagnosis and replay.
Typical setup: a consumer retries a few times with backoff, then routes the message to the DLQ along with metadata such as the original topic, error, attempt count and timestamp.
retry:
max-attempts: 5
backoff: exponential
dead-letter:
queue: orders.dlq
Operate DLQs actively: alert on non-zero depth, inspect and classify failures, fix the bug, then redrive messages after the fix. Without a redrive process a DLQ becomes a silent graveyard. Distinguish transient failures (network, downstream outage) that deserve retries from permanent ones (malformed schema, unknown type) that should skip retries. Also cap message retention and age.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.