Event-Driven System Failure Mode Analysis Prompt

This prompt is for architects and platform engineers who need to conduct a structured Failure Mode and Effects Analysis (FMEA) on an event-driven architecture before it reaches production. The job-to-be-done is identifying silent failure modes—message loss, duplicate delivery, out-of-order processing, broker failure cascades, and consumer crash scenarios—that are invisible in happy-path testing but cause data corruption and operational pain in production. The ideal user has a concrete system design in hand: a topology diagram, event schemas, broker configuration, and consumer logic. They are not looking for generic advice; they need a systematic scan of their specific architecture against known asynchronous failure patterns.

Use this prompt when you have a defined event-driven design and need to surface risks before implementation or deployment. It works best with detailed input: describe your brokers, producers, consumers, message channels, delivery guarantees, retry policies, dead-letter strategies, and idempotency mechanisms. The prompt produces a structured FMEA table with failure modes, effects, severity, detectability, and mitigation recommendations. It also flags undetected failure cascades—scenarios where one component's failure silently propagates to downstream systems without triggering alerts. This is not a prompt for initial architecture selection or high-level trade-off discussions; use the Choreography vs Orchestration Decision Prompt or Eventual Consistency Trade-Off Analysis Prompt for those decisions.

Do not use this prompt when you lack a concrete design to analyze. It cannot invent failure modes for a system you haven't described. It is also not a substitute for chaos engineering or production testing—it identifies risks for further investigation, not runtime behavior. The output requires human review: severity and detectability ratings are model judgments that must be calibrated against your operational context, SLAs, and risk tolerance. For regulated systems or financial event processing, always pair this analysis with formal verification, load testing, and operational runbooks. The next step after running this prompt is to prioritize the identified failure modes by risk score and design mitigation strategies for the top-tier items before writing consumer code.

This prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It forces a structured Failure Mode and Effects Analysis (FMEA) on an event-driven architecture by requiring the model to reason about specific failure domains—message loss, duplication, ordering, broker failure, and consumer crashes—rather than producing a generic risk list. Every placeholder is a control point you can populate programmatically or manually before execution.

textCopy
You are a senior platform architect specializing in event-driven systems. Perform a structured Failure Mode and Effects Analysis (FMEA) on the event-driven architecture described below. Your analysis must be exhaustive, specific to the provided context, and avoid generic advice.

## SYSTEM CONTEXT
[SYSTEM_DESCRIPTION]

## ARCHITECTURE ARTIFACTS
- Event Flow Diagram: [EVENT_FLOW_DESCRIPTION]
- Broker/Topic Configuration: [BROKER_TOPOLOGY]
- Consumer Group Details: [CONSUMER_GROUPS]
- Producer Configuration: [PRODUCER_CONFIGS]

## ANALYSIS CONSTRAINTS
- Risk Classification: Use [RISK_LEVEL] (Low/Medium/High/Critical) based on data integrity and business impact.
- Depth: Analyze [ANALYSIS_DEPTH] (e.g., 'happy path only', 'edge cases', 'full fault injection').
- Output Schema: Strictly adhere to the JSON schema defined in [OUTPUT_SCHEMA].

## FAILURE DOMAINS TO COVER
For each component in the flow, analyze these specific failure modes:
1. **Message Loss:** Where can a message be lost (producer fire-and-forget, broker flush interval, consumer crash before ack)?
2. **Duplicate Delivery:** Where can at-least-once semantics cause a duplicate (producer retries, consumer rebalancing)?
3. **Out-of-Order Processing:** Where can ordering guarantees break (partition rebalancing, competing consumers, retry queues)?
4. **Broker Failure:** What happens if the broker becomes unavailable (leader election, disk full, network partition)?
5. **Consumer Crash:** What happens if a consumer crashes mid-processing (offset commit timing, long-running transactions)?

## OUTPUT REQUIREMENTS
Generate a JSON object conforming to [OUTPUT_SCHEMA]. For each identified failure mode, provide:
- `failure_mode`: A concise name.
- `component`: The specific component (e.g., 'OrderProducer', 'PaymentTopic-Partition2').
- `effect`: The downstream business or data impact.
- `detection_mechanism`: How this failure would be observed (e.g., 'consumer lag metric', 'duplicate order ID in DB').
- `mitigation`: A concrete design or operational mitigation.
- `risk_level`: The classified risk level.

## ADDITIONAL CONTEXT
[ADDITIONAL_CONTEXT]

To adapt this template, replace the square-bracket placeholders with concrete details from your design documents. [SYSTEM_DESCRIPTION] should be a dense paragraph describing the business flow. [OUTPUT_SCHEMA] is critical—provide a strict JSON Schema definition to prevent the model from drifting into prose. If you are running this analysis in a CI pipeline, populate [RISK_LEVEL] and [ANALYSIS_DEPTH] from a config file to enforce consistent review standards. For high-risk systems, always route the generated FMEA to a human reviewer for approval before merging any architectural changes.

This prompt is designed to be integrated into a structured architecture review pipeline, not used as a one-off chat. The harness should treat the prompt as a deterministic analysis step that produces a machine-readable FMEA table alongside a human-readable summary. Because the output informs design decisions for production event-driven systems, the harness must enforce validation, log every invocation, and gate high-severity findings for human review before the analysis is accepted into the architecture record.

Wire the prompt as an API call with a structured output request. Use a JSON schema that enforces the FMEA table shape: each row must include failure_mode, component, severity, detection_mechanism, mitigation, and residual_risk. The harness should validate the response against this schema immediately. If validation fails, retry once with the validation error injected into the prompt as a correction instruction. If the second attempt also fails, log the failure and escalate to a human reviewer rather than silently accepting a malformed analysis. For model choice, prefer a model with strong structured output support and a context window large enough to hold the full system description plus the output schema. Claude 3.5 Sonnet or GPT-4o with response_format set to json_schema are good defaults.

The harness should also run a set of automated eval checks before the analysis reaches a human. Check that the number of identified failure modes is within a reasonable range for the system complexity described—too few suggests shallow analysis, too many suggests noise. Verify that each failure mode references a specific component or interaction in the input system description, not a generic event-driven concern. Flag any severity rating of critical or high for mandatory human review. For regulated or high-risk domains, require explicit evidence grounding: the prompt should be instructed to cite the specific architectural element that enables each failure mode, and the harness should verify that citations are present and map to components named in the input.

Log every invocation with the input system description hash, the model version, the raw and validated outputs, the eval results, and the human review decision. This audit trail is essential for architecture governance—when a failure mode that was dismissed during review later manifests in production, the team needs to trace back to the analysis that missed it. Store the validated FMEA table in a queryable format so that future architecture reviews can reference prior analyses and check whether previously identified risks were actually mitigated. Avoid treating this prompt as a fire-and-forget generator; the harness is what makes it a reliable part of the architecture review process.