sysdesign-dead-letter-queue

Implement dead-letter queues with retry, alerting, and reprocessing workflows.

Updated Apr 23, 2026

Search Tags:#messaging #alerting #idempotency #backoff #dead-letter-queue #retry-policy

Ready to run

npx skills add https://github.com/danilods/matilha-sysdesign-pack --skill sysdesign-dead-letter-queue

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: sysdesign-dead-letter-queue
Source: https://github.com/danilods/matilha-sysdesign-pack/tree/main/skills/sysdesign-dead-letter-queue
Command: npx skills add https://github.com/danilods/matilha-sysdesign-pack --skill sysdesign-dead-letter-queue

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Isolate and manage failed messages in queue/stream systems by providing a dead-letter queue (DLQ), disciplined retry with backoff, alerting on growth, and a safe reprocess-after-fix workflow.

Core Features & Use Cases

DLQ per consumer group for isolation of failures and easier remediation.
Exponential backoff with jitter to avoid thundering retries and cascading issues.
Growth alerting and retention to surface incidents without overwhelming dashboards.
Reprocess-after-fix runbook to move messages back after a patch, with safeguards for idempotency.

Quick Start

Configure your consumer to route failed messages to the DLQ and trigger the reprocess-after-fix workflow once the issue is resolved.

Frequently Asked Questions about sysdesign-dead-letter-queue

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I handle failed messages in SQS or Kafka without losing data?▼

A dead-letter queue (DLQ) isolates failed messages by routing them out of the main queue for later inspection. This ensures transient or permanent failures do not block your consumer group and prevents data loss.

What is the best way to implement a retry policy with exponential backoff for messaging queues?▼

An effective retry policy uses exponential backoff with jitter to delay message reprocessing. Adding jitter prevents thundering retries and cascading system overloads during transient failure recovery in queue-based architectures.

When do I need a dead-letter queue for my message-consuming services?▼

You need a dead-letter queue when isolating messages that exhaust retry limits due to permanent failures. It separates toxic messages from the main stream, allowing your service to continue processing valid messages without disruption.

How do I safely reprocess messages from a dead-letter queue after a patch?▼

Reprocess DLQ messages using a reprocess-after-fix runbook that verifies the patch and moves messages back to the main queue. Safeguards for idempotency are required to prevent duplicate side effects during reprocessing.

Does this dead-letter queue strategy work with RabbitMQ and Pub/Sub?▼

Yes, the dead-letter queue strategy applies to queue- or stream-based architectures including RabbitMQ, Pub/Sub, SQS, and Kafka. It configures consumers to route failed messages to a dedicated DLQ per consumer group for isolation.

Why do I need alerting and retention configured on my dead-letter queue?▼

Growth alerting and retention on a dead-letter queue surface incidents without overwhelming dashboards. Alerting triggers when the DLQ grows, ensuring you remediate failures promptly, while retention manages storage lifecycle.