Backpressure Handling Design Prompt

This prompt is designed for SREs and platform engineers who need a structured, design-level review of backpressure handling mechanisms in an event-driven pipeline. The core job-to-be-done is to prevent cascading failures by ensuring that when consumers cannot keep pace with producers, the system degrades gracefully rather than collapsing. Use this prompt when you have a defined event pipeline topology with known producers, brokers, and consumers, and you need to assess the completeness of your backpressure strategy, identify failure propagation risks, and define degradation paths. It is most effective during architecture reviews, pre-production readiness checks, or incident postmortems where backpressure gaps were identified as a contributing factor.

The prompt assumes you can provide a detailed description of your pipeline topology, including the broker technology (e.g., Kafka, RabbitMQ, SQS), consumer scaling model, current queue depth limits, and any existing throttling or retry logic. It does not require production metrics, but the analysis will be more actionable if you include known consumer lag thresholds and processing time SLAs. The model will produce a structured review covering consumer lag detection, producer throttling strategies, queue depth limits, and graceful degradation paths. It will also flag missing mechanisms, such as the absence of a circuit breaker on a producer or an unbounded retry policy that could amplify backpressure.

Do not use this prompt as a substitute for load testing, capacity planning, or real-time monitoring. It provides a design-level analysis, not a runtime safety guarantee. The prompt will not simulate traffic patterns or calculate exact queue sizing, and it cannot validate whether your chosen broker configuration can handle a specific throughput. For high-risk systems where backpressure failure could cause data loss or a complete service outage, always pair this design review with empirical load testing and a human review of the generated strategy by an engineer familiar with the production environment. The next step after running this prompt is to take the identified gaps and turn them into implementation tasks, then validate the fixes under load.

This prompt template is the core of the Backpressure Handling Design Playbook. It is designed to be pasted directly into your AI workflow, instructing the model to act as a Site Reliability Engineer (SRE) reviewing a specific event pipeline. The prompt forces a structured analysis of consumer lag, producer throttling, queue depth, and graceful degradation, ensuring the output is a practical design review rather than a generic explanation of backpressure.

textCopy
You are an SRE reviewing the backpressure handling design for an event-driven pipeline. Your goal is to produce a structured Backpressure Strategy Review that identifies failure modes and recommends concrete mechanisms.

## System Context
[SYSTEM_DESCRIPTION: Describe the pipeline, including producers, broker/queue, consumers, and the criticality of the data flow.]

## Current Design
[CURRENT_DESIGN: Detail the existing or proposed backpressure mechanisms, if any. Include consumer concurrency, prefetch counts, queue limits, and any throttling logic.]

## Review Criteria
Analyze the current design against the following dimensions and provide specific, actionable findings for each:
1.  **Consumer Lag Thresholds:** Define safe vs. critical lag limits. How should the system detect and alert on lag?
2.  **Producer Throttling:** What mechanisms should slow down or stop producers (e.g., HTTP 429/503, gRPC backpressure, flow control)?
3.  **Queue Depth Limits:** What are the maximum queue depths? What happens when they are exceeded (e.g., reject new messages, drop oldest, dead-letter)?
4.  **Graceful Degradation:** How should the system shed load non-destructively? What features or message types can be deprioritized or paused first?
5.  **Cascading Failure Prevention:** How does this design prevent a slow consumer from starving other consumers or crashing the broker?

## Output Schema
Return your analysis as a JSON object with the following structure. Do not wrap the JSON in markdown.
{
  "backpressure_strategy_review": {
    "pipeline_identifier": "string",
    "overall_risk_assessment": "low_risk | medium_risk | high_risk | critical_risk",
    "findings": [
      {
        "dimension": "Consumer Lag Thresholds | Producer Throttling | Queue Depth Limits | Graceful Degradation | Cascading Failure Prevention",
        "finding": "string (specific observation about the current design)",
        "risk": "low | medium | high | critical",
        "recommendation": "string (concrete, actionable change)"
      }
    ],
    "critical_gaps": ["string (list of the most dangerous missing mechanisms)"],
    "implementation_priority": ["string (ordered list of actions, highest priority first)"]
  }
}

## Constraints
- Base every finding on the provided [SYSTEM_DESCRIPTION] and [CURRENT_DESIGN]. Do not invent details.
- Recommendations must be specific (e.g., 'Set the channel prefetch count to 10' not 'Adjust the prefetch count').
- If the current design is missing a mechanism entirely, state that explicitly and recommend one.

To adapt this template, replace the [SYSTEM_DESCRIPTION] and [CURRENT_DESIGN] placeholders with details from your architecture. The [SYSTEM_DESCRIPTION] should be a concise paragraph, while the [CURRENT_DESIGN] can be a bulleted list of existing configurations. The output schema is rigidly defined as JSON to allow for direct parsing in an automated CI/CD pipeline or architecture review harness. For high-risk pipelines, always route the final backpressure_strategy_review JSON to a human SRE for approval before implementing any recommendations.

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 or architecture review tool that submits a system design document, event topology diagram, or pipeline configuration and expects a structured backpressure assessment in return. The prompt expects [SYSTEM_DESIGN] and [CONSTRAINTS] as inputs, and the application layer is responsible for assembling these from design docs, architecture decision records, or infrastructure-as-code definitions before invoking the model.

Wire the prompt into a review harness that enforces a strict output schema. After the model returns a response, validate that the JSON output contains all required fields: consumer_lag_thresholds, producer_throttling_strategy, queue_depth_limits, graceful_degradation_plan, and cascading_failure_risks. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. Log both the initial response and the retry attempt for traceability. For production use, route all assessments that flag cascading_failure_risks with severity high to a human review queue before the design is accepted. This is not optional—backpressure failures in event pipelines can cause silent data loss that propagates across services before any alert fires.

Choose a model with strong structured output support and a context window large enough to hold the full system design plus the prompt instructions. GPT-4o and Claude 3.5 Sonnet both perform well on this task when output is constrained with a JSON schema. Avoid smaller or older models that may drop required fields or hallucinate threshold values. If the system design references specific queue technologies (Kafka, RabbitMQ, SQS), include those technology constraints in [CONSTRAINTS] so the model can recommend implementation-appropriate patterns rather than generic advice. Do not use this prompt for real-time operational decisions—it is a design-time review tool, not a runtime circuit breaker. For runtime backpressure, implement the reviewed design in application code with actual metric thresholds and automated throttling, not model calls.