Dead Letter Queue Design Prompt

This prompt is for platform engineers and architects who need a structured design review of a Dead Letter Queue (DLQ) strategy before it ships to production. The job-to-be-done is not to generate a DLQ from scratch, but to pressure-test an existing design against known failure modes: poison message amplification, silent data loss, replay ordering violations, and observability gaps. The ideal user has a concrete DLQ design in hand—retention policies, replay mechanisms, alerting thresholds, and consumer contracts—and needs an adversarial review that surfaces what will break first under real load.

Use this prompt when you have a written DLQ design document, a draft runbook, or a set of architectural decisions that need validation. It works best when you provide the full context: the messaging infrastructure (Kafka, RabbitMQ, SQS, etc.), the consumer topology, the expected failure modes you've already considered, and any operational constraints like retention windows or compliance requirements. The prompt is designed to produce a structured review with specific, actionable gaps—not generic advice. It will flag missing alerting on DLQ depth, replay mechanisms that lack idempotency guards, and retention policies that don't align with your recovery time objectives.

Do not use this prompt as a substitute for load testing, chaos engineering, or operational readiness reviews. It will not simulate broker behavior under partition loss or network partition. It is a design review tool, not a verification tool. If your system handles regulated data (PCI, PHI, PII), the prompt will flag the need for human review of data retention in the DLQ, but it cannot certify compliance. For high-risk systems, always pair this prompt's output with a formal failure mode and effects analysis (FMEA) and a legal review of data-at-rest policies in your dead letter storage.

This prompt template is the core of the DLQ design playbook. It's engineered to guide a model through a systematic review of a dead letter queue strategy, not just to describe what a DLQ is. The placeholders force you to provide the concrete details—retention policies, replay mechanisms, alerting thresholds—that turn a generic discussion into an actionable, system-specific audit. Copy the block below and replace every square-bracket placeholder with your system's actual configuration and constraints before sending it to the model.

textCopy
You are a senior platform engineer specializing in resilient event-driven architectures. Your task is to conduct a rigorous design review of a Dead Letter Queue (DLQ) strategy. You will evaluate the strategy for completeness, safety, and operational readiness. Do not provide generic advice; ground every finding in the specific details provided in the [SYSTEM_CONTEXT].

**System Context:**
[SYSTEM_CONTEXT]

**DLQ Strategy Document:**
[DLQ_STRATEGY_DOCUMENT]

**Review Criteria:**
1.  **Retention and Storage:** Evaluate the DLQ message retention policy, storage limits, and data lifecycle. Is the retention window long enough for operational diagnosis? Is there a risk of disk exhaustion?
2.  **Replay and Recovery:** Analyze the replay mechanism. Is it automated or manual? Is it idempotent? Does it respect message ordering where required? Identify any risks of side effects or data corruption during replay.
3.  **Alerting and Monitoring:** Assess the alerting thresholds and monitoring metrics. Will the on-call team be notified before the DLQ becomes a critical problem? Are there metrics for DLQ depth, message age, and processing error rates?
4.  **Poison Message Handling:** Review the strategy for handling poison messages that cannot be processed even after retries. Is there a quarantine procedure? How are these messages analyzed and resolved to prevent recurrence?
5.  **Observability and Traceability:** Evaluate how message lineage and trace context (e.g., correlation IDs) are preserved for messages in the DLQ. Can an operator trace a failed message back to its origin?
6.  **Operational Runbooks:** Assess whether the strategy includes or implies clear runbooks for common operational tasks: inspecting messages, purging a queue, and performing a bulk replay.

**Output Schema:**
Produce a structured JSON object with the following keys:
- `overall_assessment`: A one-sentence summary of the strategy's maturity (e.g., "Mature and production-ready with minor gaps in replay idempotency").
- `findings`: An array of objects, each representing a specific finding. Each object must have the keys `severity` ("CRITICAL", "HIGH", "MEDIUM", "LOW"), `category` (from the review criteria list), `finding` (a concise description of the issue or strength), and `recommendation` (a concrete, actionable step to resolve the issue or solidify the strength).
- `recoverability_score`: A score from 1 to 5, where 1 means "unrecoverable data loss is likely" and 5 means "fully automated, safe, and observable recovery is in place."
- `observability_gaps`: An array of strings listing specific metrics, logs, or traces that are missing and would hinder debugging during an incident.

**Constraints:**
- Base every finding on evidence from the [DLQ_STRATEGY_DOCUMENT]. If a criterion cannot be evaluated due to missing information, create a `MEDIUM` severity finding stating that the area is undocumented.
- Do not invent features or policies that are not described in the provided document.
- The `recommendation` field must be a direct instruction, not a question.

To adapt this template, start by replacing [SYSTEM_CONTEXT] with a brief description of your messaging infrastructure (e.g., "AWS SQS with Lambda consumers processing payment events"). The [DLQ_STRATEGY_DOCUMENT] placeholder should be filled with the actual text of your design proposal, runbook, or configuration notes. The output schema is designed to be machine-readable, so you can pipe the results directly into an internal dashboard or compliance tracker. If your review requires a specific risk tolerance, add a [RISK_TOLERANCE] placeholder to the constraints, such as "This is a high-severity financial system; any risk of duplicate processing is a CRITICAL finding."

This prompt is designed to be called programmatically as part of a design review pipeline, not as a one-off chat interaction. The typical integration point is a CI/CD check, an architecture review bot, or a pull request reviewer that scans proposed event-driven system changes. The prompt expects a structured [DESIGN_SPEC] input containing the proposed DLQ topology, retention policies, replay mechanisms, and alerting thresholds. The output is a structured review document that downstream systems can parse for pass/fail gating.

Wire the prompt into your application by constructing the [DESIGN_SPEC] payload from your architecture documentation or design proposal. Before calling the model, validate that required fields are present: dlq_topology, retention_policy, replay_mechanism, alerting_thresholds, and poison_message_strategy. If any field is missing, return a 400 error to the caller rather than sending an incomplete prompt. After receiving the model response, parse the structured output against the expected [OUTPUT_SCHEMA]—typically a JSON object with findings, risks, recommendations, and eval_scores arrays. Run automated eval checks: verify that eval_scores.recoverability >= 0.7, that eval_scores.observability_gaps is not empty, and that no finding has a severity: critical without a corresponding recommendation. If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. If the retry also fails, escalate to a human reviewer via your ticketing system.

For high-risk systems—those handling financial transactions, healthcare data, or compliance-critical events—add a mandatory human approval step before any design review is accepted. Log every prompt invocation, the raw model response, validation results, and the final disposition (passed, failed, escalated) to your observability platform. Include the correlation_id from the [DESIGN_SPEC] in all logs so you can trace the review back to the originating design document. Avoid using this prompt for real-time operational decisions; it is a design-time review tool, not a runtime DLQ monitor. For runtime monitoring, pair this with a separate observability prompt that analyzes production DLQ metrics and consumer lag.