Build a Queue Worker with Backoff and a Dead-Letter Queue
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: medium
Interview Round: Onsite
Design a queue and a worker that retrieves tasks, retries failures with exponential backoff, and moves tasks to a dead-letter queue after a retry limit. Explain how you would use an AI assistant to develop the implementation and assess its tradeoffs.
### Constraints & Assumptions
This is a real worker-lifecycle and failure-handling exercise. The source does not specify a broker, language, retry count, or persistence guarantees. State your delivery and retry semantics before coding. AI-assisted drafting is part of the reported discussion, not a substitute for understanding the result.
### Clarifying Questions
Does the limit count attempts or retries? Which errors are retryable? What happens if a worker crashes after a task effect but before acknowledgment? How durable must delayed retries and the dead-letter queue be?
### What a Strong Answer Covers
Define task states, attempt ownership, delayed retries, durable failure handling, and idempotent effects. Show how a generated design would be tested for crash boundaries and concurrency.
### Follow-up Questions
How would you cap and jitter the delay? What information belongs in a dead-letter record? How would you safely replay it after a bug fix?
Overview: Design queue-worker retries with exponential backoff, durable delayed delivery, attempt limits, idempotent effects, and dead-letter replay, including AI-code validation.
Design a queue and a worker that retrieves tasks, retries failures with exponential backoff, and moves tasks to a dead-letter queue after a retry limit. Explain how you would use an AI assistant to develop the implementation and assess its tradeoffs.
Constraints & Assumptions
This is a real worker-lifecycle and failure-handling exercise. The source does not specify a broker, language, retry count, or persistence guarantees. State your delivery and retry semantics before coding. AI-assisted drafting is part of the reported discussion, not a substitute for understanding the result.
Clarifying Questions Guidance
Does the limit count attempts or retries? Which errors are retryable? What happens if a worker crashes after a task effect but before acknowledgment? How durable must delayed retries and the dead-letter queue be?
What a Strong Answer Covers Guidance
Define task states, attempt ownership, delayed retries, durable failure handling, and idempotent effects. Show how a generated design would be tested for crash boundaries and concurrency.
Follow-up Questions Guidance
How would you cap and jitter the delay? What information belongs in a dead-letter record? How would you safely replay it after a bug fix?