Message Queue Dead Letter Strategy Prompt

Use this prompt when you need a structured, critical review of a dead letter queue (DLQ) strategy for an asynchronous messaging system. It is designed for platform engineers and SREs who must define how unprocessable messages are detected, routed, stored, replayed, and alerted on. The prompt assumes you have a system design document, message flow diagram, or existing queue configuration to review. It produces a strategy assessment covering poison message detection rules, DLQ routing logic, replay mechanisms, alerting thresholds, and operational runbooks. This is a design-time review prompt, not an incident response tool. Run it before implementing DLQ handling or when auditing an existing system for resilience gaps.

The prompt works best when you provide concrete context: your message broker type (e.g., RabbitMQ, SQS, Kafka), consumer architecture, message schema, and current retry policies. Without this context, the review will be generic and miss implementation-specific failure modes. The prompt is not a replacement for load testing or chaos engineering; it identifies design gaps that those tests would later expose. Do not use this prompt during an active production incident—it is too slow and deliberative for that context. Instead, use it during architecture review meetings, pre-implementation design sessions, or scheduled resilience audits.

Before running this prompt, gather your system's current DLQ configuration, message flow diagrams, consumer code patterns, and any existing incident reports related to message processing failures. The prompt will ask you to evaluate detection rules, routing logic, replay safety, and alerting coverage. After the review, prioritize the findings by risk severity and schedule remediation for any gap rated 'High' or 'Critical.' Avoid the temptation to only fix alerting gaps; silent data loss and infinite retry loops are harder to detect and often more damaging than missing alerts.

The following prompt template is designed to produce a structured, actionable review of your dead letter queue (DLQ) strategy. It forces the model to reason about poison message detection, routing rules, replay mechanisms, and alerting thresholds before generating a response. Copy the template, replace the square-bracket placeholders with your system's specific context, and run it against a capable model. The output should be a detailed strategy assessment you can take directly to an architecture review or implementation planning session.

codeCopy
You are a senior resilience architect reviewing a dead letter queue strategy for a distributed messaging system. Your review must be thorough, evidence-based, and focused on preventing silent data loss, infinite retry loops, and operational blind spots.

## SYSTEM CONTEXT
[SYSTEM_DESCRIPTION: Brief description of the messaging system, its purpose, and its criticality.]

## CURRENT DLQ CONFIGURATION
[DLQ_CONFIG: Describe the current DLQ setup, including the message broker, queue topology, and any existing DLQ routing rules.]

## MESSAGE PROCESSING PIPELINE
[PROCESSING_PIPELINE: Describe how messages are consumed, processed, and acknowledged. Include retry policies, timeout settings, and any existing error handling.]

## CONSTRAINTS
[CONSTRAINTS: List any constraints such as latency requirements, data sensitivity, compliance obligations, or operational limitations.]

## REVIEW CRITERIA
Evaluate the DLQ strategy against the following dimensions. For each, provide a severity rating (Critical, High, Medium, Low), a detailed finding, and a concrete remediation recommendation.

1. **Poison Message Detection**: How are unprocessable messages identified and moved to the DLQ? Are there clear criteria for what constitutes a poison message versus a transient failure?
2. **DLQ Routing Rules**: Are messages routed to the correct DLQ based on failure type, source service, or error classification? Is the routing granular enough for effective diagnosis and replay?
3. **Replay Mechanisms**: Is there a safe, auditable mechanism for replaying messages from the DLQ back to the primary queue or a designated recovery pipeline? Does it preserve original ordering and metadata?
4. **Alerting and Monitoring**: What thresholds trigger alerts for DLQ depth, message age, or replay failures? Are there alerts for an empty DLQ that should contain messages (indicating silent loss)?
5. **Data Integrity and Loss Prevention**: Are there any scenarios where messages could be silently dropped before reaching the DLQ? Are DLQ messages persisted durably?
6. **Operational Runbooks**: Is there a documented procedure for DLQ triage, message inspection, selective replay, and purging? How would an on-call engineer respond to a DLQ alert at 3 AM?

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "executive_summary": "A 2-3 sentence summary of the overall DLQ strategy health and the most critical risk.",
  "findings": [
    {
      "dimension": "One of the six review criteria above",
      "severity": "Critical | High | Medium | Low",
      "finding": "A specific, evidence-based description of the gap or risk identified.",
      "remediation": "A concrete, actionable recommendation to address the finding."
    }
  ],
  "risk_matrix": {
    "silent_data_loss_risk": "High | Medium | Low",
    "infinite_retry_loop_risk": "High | Medium | Low",
    "operational_blind_spot_risk": "High | Medium | Low"
  },
  "prioritized_action_items": ["Ordered list of the top 3-5 actions to take, starting with the most urgent."]
}

Before generating the final output, reason step-by-step through each review criterion, considering how the described configuration could fail under production conditions.

To adapt this template, replace each square-bracket placeholder with details specific to your system. The [SYSTEM_DESCRIPTION] should give the model enough context to understand the criticality and domain of the messaging system. The [DLQ_CONFIG] and [PROCESSING_PIPELINE] placeholders are where you describe the current state—be honest about what exists today, even if it is incomplete. The [CONSTRAINTS] section is essential for grounding the review in real-world limitations; a theoretically perfect DLQ design that violates a latency SLO or compliance requirement is not a useful recommendation.

After running the prompt, validate the output against the expected JSON schema before acting on any findings. If the model produces a severity rating that seems misaligned with your operational reality, re-run with additional context in the constraints section. For high-risk systems where data loss is unacceptable, route the model's findings through a human architecture review before implementing any remediation. This prompt is a diagnostic tool, not a replacement for engineering judgment.

This prompt is designed to be called programmatically as part of a design review pipeline, not as a one-off chat interaction. The harness should feed the prompt a structured [CONTEXT] object containing the message queue topology, current DLQ configuration, consumer behavior, and any existing incident history. The model's output is a structured strategy review, which the harness must validate before it is accepted into your architecture knowledge base or ticketing system.

Implement the harness with a strict JSON schema validator that checks for the required sections: poison message detection rules, DLQ routing rules, replay mechanism design, and alerting thresholds. If the output fails schema validation, retry once with the validation errors appended to the [CONSTRAINTS] field. After two failures, route the request to a human reviewer with the partial output and error log attached. Log every invocation—including the prompt version, model used, input hash, output, and validation result—to your observability platform for audit and drift detection.

For high-risk production queues, add an eval step that runs the output through a set of adversarial test cases before acceptance. These tests should simulate silent data loss scenarios (e.g., a message is moved to DLQ but never logged) and infinite retry loops (e.g., a replay mechanism that re-enqueues poison messages without mutation). If the generated strategy does not explicitly address both failure modes, flag the output for mandatory human review. Never auto-apply a DLQ strategy change to production infrastructure without a human approval gate, regardless of eval scores.