Event-Driven Anti-Pattern Detection Prompt

This prompt is for architects and platform engineers who need to review event-driven system designs for common anti-patterns before implementation begins. It produces a structured anti-pattern scan covering event-carried state transfer, distributed monolith signals, tight temporal coupling, missing schema registries, and other failure patterns that cause silent data loss and operational fragility in production. The prompt assumes you have a design description, architecture diagram text, or AsyncAPI specification to analyze. It is not a replacement for runtime observability or load testing, and it does not review implementation code.

Use this prompt during architecture review boards, design document evaluations, or as a pre-commit gate for event-driven service proposals. The output is a categorized list of detected anti-patterns, each with a severity rating, a description of the risk, and a concrete remediation recommendation. The prompt is calibrated to flag structural design problems—not style preferences or implementation details. For code-level event handler review, use the Idempotency Design Review Prompt or the Outbox Pattern Implementation Review Prompt instead. For runtime behavior analysis, pair this prompt with the Event-Driven Observability Strategy Prompt.

Before running this prompt, gather the design artifact you want reviewed: an architecture diagram description, an AsyncAPI specification, a design document, or a written summary of the proposed event flow. The prompt works best when the input includes explicit information about event schemas, producer-consumer relationships, delivery guarantees, error handling strategies, and schema evolution plans. If your design document is sparse on these details, the prompt will flag missing information as a risk in itself—which is often the most valuable finding. After receiving the output, validate each flagged anti-pattern against your actual system constraints. Not every flag is a defect; some are acceptable trade-offs. The harness section below describes how to calibrate false positive rates for your organization's risk tolerance.

This prompt template performs a structured anti-pattern scan on an event-driven architecture description. It evaluates the design against known failure modes including event-carried state transfer, tight temporal coupling, missing schema registries, distributed monolith signals, and orphaned subscribers. The output is a machine-readable report suitable for ingestion into architecture review pipelines, decision logs, or CI/CD quality gates. Copy the template below into your AI harness, replace the square-bracket placeholders with actual values, and run it against your architecture documentation or design proposals.

textCopy
You are an event-driven architecture reviewer. Your task is to scan the provided architecture description for common anti-patterns and produce a structured report.

## INPUT
Architecture Description:
[ARCHITECTURE_DESCRIPTION]

Supporting Artifacts (optional):
[SUPPORTING_ARTIFACTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "scan_summary": {
    "total_anti_patterns_found": <integer>,
    "critical_count": <integer>,
    "warning_count": <integer>,
    "info_count": <integer>
  },
  "findings": [
    {
      "id": "AP-<incrementing-number>",
      "anti_pattern": "<name from catalog below>",
      "severity": "critical|warning|info",
      "location": "<specific component, service, or interaction path>",
      "evidence": "<quote or describe the design element that triggers this finding>",
      "impact": "<what breaks, degrades, or becomes unmaintainable>",
      "remediation": "<concrete design change or mitigation>",
      "false_positive_risk": "low|medium|high",
      "requires_human_review": <true|false>
    }
  ],
  "false_positive_notes": [
    "<explanation for any finding with high false_positive_risk>"
  ]
}

## ANTI-PATTERN CATALOG
Scan for these anti-patterns. Only report findings where evidence exists in the input.

1. **Event-Carried State Transfer**: Events that carry full entity state rather than domain intent, causing consumers to reconstruct remote state and creating hidden coupling to producer internal models.

2. **Tight Temporal Coupling**: Design that assumes events arrive within specific time windows, uses synchronous request-response over event channels, or lacks timeout and staleness handling.

3. **Missing Schema Registry**: Events defined without a schema registry, versioned schema store, or contract enforcement mechanism, leading to unversioned payloads and breaking changes without detection.

4. **Distributed Monolith Signal**: Services that emit fine-grained CRUD events mirroring database operations rather than business-domain events, indicating the system is a distributed monolith rather than a truly event-driven architecture.

5. **Orphaned Subscriber**: Subscribers with no clear ownership, no alerting on consumer lag, or no documented recovery procedure when the subscriber fails permanently.

6. **Circular Event Flow**: Events that trigger downstream processing which eventually produces events consumed upstream, creating feedback loops without termination conditions.

7. **Missing Correlation Context**: Events lacking trace IDs, causation IDs, or correlation identifiers, making distributed debugging and observability impossible.

8. **No Dead Letter Strategy**: Absence of dead letter queues, poison message handling, or unprocessable message routing for any event channel.

9. **Implicit Ordering Dependency**: Consumers that depend on event arrival order without explicit sequence numbers, timestamps, or ordering guarantees documented in the design.

10. **Missing Idempotency Design**: Event handlers without idempotency keys, deduplication storage, or at-least-once delivery handling, risking duplicate processing on retry.

11. **Event Type Explosion**: Proliferation of fine-grained event types that mirror internal implementation details rather than stable business events, creating versioning and maintenance burden.

12. **Synchronous Bridge Over Events**: Using event infrastructure to implement synchronous request-response patterns, defeating the decoupling benefits of asynchronous messaging.

## CONSTRAINTS
- Only report findings where the architecture description provides sufficient evidence.
- Do not invent anti-patterns not present in the input.
- For each finding rated critical, set requires_human_review to true.
- If a finding could be a false positive due to missing context, set false_positive_risk to high and explain in false_positive_notes.
- If the architecture description is insufficient to complete a thorough scan, return a partial scan with a note in scan_summary indicating coverage gaps.
- Do not recommend specific vendor products unless the input already references them.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

Adaptation guidance: Replace [ARCHITECTURE_DESCRIPTION] with the full text of the design document, ADR, or architecture diagram description you want to scan. Use [SUPPORTING_ARTIFACTS] for related event schemas, AsyncAPI specs, or sequence diagrams that provide additional context. Set [RISK_LEVEL] to the review context: "production-blocking" for pre-deployment gates, "advisory" for design reviews, or "exploratory" for early-stage architecture sketching. The [EXAMPLES] placeholder accepts few-shot examples of correct findings to calibrate severity judgment for your organization's risk tolerance. If your architecture spans multiple bounded contexts, run the scan once per context to keep findings scoped and actionable.

Validation and integration: Before integrating this prompt into a CI/CD pipeline, run it against a golden dataset of known architecture descriptions with labeled anti-patterns. Measure precision and recall per anti-pattern type. Pay special attention to false positive rates on Event-Carried State Transfer and Distributed Monolith Signal, which are the most context-sensitive detections. For production use, route findings with requires_human_review: true or severity: critical to an architecture review queue rather than auto-blocking deployments. Store scan results alongside the architecture version they reference so findings remain traceable as the design evolves.

The Event-Driven Anti-Pattern Detection Prompt is designed to operate as a gated analysis step within a broader architecture review workflow, not as a standalone chatbot query. In production, you should wrap this prompt in a harness that controls input assembly, output validation, retry logic, and human review routing. The prompt expects a structured architecture description as input—typically a markdown document, an ADR draft, or a system design brief that describes event flows, schema decisions, and messaging topology. Before calling the model, your harness should validate that the input contains sufficient detail: at minimum, a description of event types, producer-consumer relationships, and serialization or schema choices. If the input is too sparse, the harness should reject the request early and ask for more context rather than producing a low-confidence anti-pattern scan full of false positives.

After the model returns its structured output, the harness must validate the response schema before the results reach a reviewer. The prompt template includes an [OUTPUT_SCHEMA] placeholder that should be populated with a JSON Schema definition requiring fields such as anti_patterns (an array of findings), severity, evidence, and recommendation. Your harness should parse the model output and check that every required field is present, that severity values fall within an allowed enum (e.g., CRITICAL, HIGH, MEDIUM, LOW), and that each finding includes a specific evidence reference tied to the input. If validation fails, the harness should retry with the same input and a repair instruction appended, up to a configurable maximum (we recommend 2 retries). After two failed validation attempts, escalate to a human review queue with the raw output and validation errors attached. This prevents silent acceptance of malformed analysis while avoiding infinite retry loops that waste tokens.

For model selection, use a model with strong reasoning capabilities and reliable structured output support—GPT-4o, Claude 3.5 Sonnet, or equivalent. The prompt's anti-pattern detection task requires nuanced pattern matching across architectural descriptions, and weaker models tend to produce either overly generic findings or miss subtle coupling signals. Set the temperature low (0.0–0.2) to maximize consistency across runs, especially if you plan to compare anti-pattern scans over time as the architecture evolves. If your architecture documents are long, consider splitting the input into sections (event catalog, topology diagram description, schema definitions) and running the prompt once with the full assembled context rather than chunking, because many anti-patterns—such as distributed monolith signals—only become visible when you see the full producer-consumer graph together.

Logging and observability are critical because this prompt influences architectural decisions that have long-term cost and reliability implications. Your harness should log the prompt version, model identifier, input hash, output validation status, retry count, and final disposition (accepted, repaired, or escalated). Store these logs alongside the architecture document version so that future reviewers can trace which anti-pattern scan corresponded to which design iteration. If your organization maintains a design review checklist or approval workflow, integrate the validated anti-pattern output as a required artifact before architecture sign-off. This creates an audit trail showing that event-driven risks were explicitly considered, not assumed away.

Finally, calibrate for false positives before trusting the output in production. Run the prompt against a set of known-clean architecture descriptions (designs you've already reviewed and confirmed do not exhibit the target anti-patterns) and measure the false positive rate. If the prompt flags issues in clean designs, adjust the [CONSTRAINTS] section to add calibration guidance—for example, instructing the model to require at least two distinct evidence signals before reporting a finding, or to distinguish between 'pattern present' and 'pattern risk exists but mitigated.' This calibration step is essential because an over-eager anti-pattern detector erodes trust and creates review fatigue. Once calibrated, the harness can route CRITICAL findings for mandatory human review while allowing LOW-severity findings to be acknowledged as informational, keeping the review process focused on genuine architectural risks.