I need a queue with dead-letter queues and poison-message handling, what options are there?

There are a few common ways to get queues with dead-letter queues (DLQs) and poison-message handling, depending on whether you want a managed cloud service, an open-source broker, or a custom/app-level pattern.

Main options

1) Cloud-managed queues

These usually have DLQ support built in.

AWS SQS

• Native dead-letter queues
• Configurable redrive policy with max receive count
• Good for simple, highly available work queues
• “Poison” messages are automatically moved to DLQ after repeated failures

Azure Service Bus

• Native dead-letter subqueues
• Supports manual dead-lettering with a reason/error description
• Strong enterprise features: sessions, duplicate detection, transactions
• Very good if you need richer messaging semantics

Google Cloud Pub/Sub

• Supports dead-letter topics
• Subscription can forward messages after a configurable delivery attempt count
• Good if you’re already in GCP

---

2) Message brokers / queue systems

These often support DLQ patterns, but the details vary.

RabbitMQ

• No single “DLQ product” as a separate feature, but supports dead-letter exchanges (DLX)
• Messages can be routed to a DLX when:
  • rejected/nacked
  • expired
  • queue length limits are hit
• Flexible, widely used, good if you want control over routing

Apache Kafka

• Kafka itself doesn’t have a classic queue/DLQ model built in
• Common pattern: create a DLQ topic
• Consumer app sends failed records there after retry attempts
• Great for event streaming, less like a traditional queue

ActiveMQ / Artemis

• Supports dead-letter queues
• Mature enterprise messaging
• Often used in Java-heavy environments

Redis-based queues

• Examples: BullMQ, RQ, Celery + Redis
• DLQ/failed-job queues are usually handled by the framework rather than Redis itself
• Good for job queues, not as strong for broker-level guarantees

---

3) Job queue frameworks with built-in retry/failure queues

If your “queue” is really background jobs, these are often the easiest.

Celery

• Retry policies, reject/ack behavior
• Can route failed tasks to a failed-task backend/pattern
• Common with RabbitMQ/Redis

Sidekiq

• Retries and a “dead set” for exhausted jobs
• Popular in Ruby ecosystems

BullMQ

• Built-in retries, stalled jobs, failed job handling
• Redis-backed

Hangfire

• Retries and failed job dashboard
• Good in .NET

---

What “poison-message handling” usually means

A poison message is one that keeps failing processing due to bad data, schema mismatch, or a code bug.

Typical handling patterns:

1. Retry with backoff a limited number of times
2. If still failing, move to DLQ
3. Log/alert with message payload and failure reason
4. Provide a replay/reprocess path after fixing the issue

Important detail: don’t retry forever, or the poison message can block progress and waste resources.

---

What to look for when choosing

Key capabilities:

• Max retry count / receive count
• Automatic DLQ routing
• Visibility timeout / message lock
• Manual dead-lettering
• Poison message metadata: error reason, exception details, original queue/topic
• Replay tooling
• Ordering guarantees if you need them
• Exactly-once vs at-least-once semantics

---

Quick recommendations

• Simplest cloud queue with DLQ: AWS SQS
• Enterprise messaging with rich dead-lettering: Azure Service Bus
• Flexible broker with DLQ routing: RabbitMQ
• Streaming/event backbone: Kafka + DLQ topic
• Background job queue: Sidekiq / Celery / BullMQ / Hangfire

If you want, I can also give you:

1. a comparison table,
2. recommendations by cloud/provider/language, or
3. an architecture pattern for retries + DLQ + poison-message monitoring.