Dead-letter queues

Messages that fail processing a set number of times are moved aside for inspection, so one bad message does not block the queue or burn worker capacity forever.

Where it shows up in real systems

  • Message queue

    A queue absorbs spikes: the API answers as soon as the message is stored, and workers drain the backlog at their own pace. Standard queues deliver at least once and may reorder; FIFO queues keep order but cap throughput. Messages that fail repeatedly go to a dead-letter queue.

    In production: Amazon SQS, RabbitMQ, Azure Service Bus, Google Cloud Tasks

  • Dead-letter queue

    Without it, a poison message is retried forever and wastes worker capacity. With it, the message is isolated after a set number of deliveries and an engineer can inspect and replay it.

    In production: Amazon SQS DLQ, RabbitMQ dead-letter exchange, Kafka DLQ topic

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox