Connection Pool Resilience Audit Prompt

This prompt is designed for backend engineers, platform engineers, and SREs who need a structured, pre-production audit of database or service connection pool configurations. The primary job-to-be-done is to catch configuration-level risks—such as sizing mismatches, missing timeouts, and exhaustion handling gaps—that are easy to overlook in code review but can cause cascading failures under load. Use it during design reviews, pre-launch readiness checks, or as a structured post-incident remediation step to ensure the fix addresses the root configuration weakness, not just the symptom.

The ideal input is a raw configuration snippet (e.g., a HikariCP, pgbouncer.ini, or Node.js pool config), a set of pool metrics from a monitoring dashboard, or internal documentation describing the intended pool behavior. The prompt works by cross-referencing the provided configuration against known resilience patterns for connection storms, slow-query saturation, and leak detection. It does not require a running system, which makes it valuable before load tests are written. However, it is not a replacement for production observability, load testing, or chaos engineering. It will not catch application-level connection leaks caused by unclosed resources in code, nor can it validate that your chosen pool size is correct for your specific traffic shape without real metrics.

Do not use this prompt when you need a performance benchmark, a real-time incident response playbook, or a security audit of your authentication credentials. It is also the wrong tool if you have no configuration to audit and are instead looking for general advice on which connection pool library to choose. For the best results, provide concrete configuration values. Vague inputs like 'we use the default settings' will produce a vague audit. After running the audit, treat the output as a prioritized checklist for your team to review and test, not as a final sign-off. The next step is to validate the highest-severity findings with targeted load tests before deploying to production.

This prompt template is designed to be copied directly into your AI orchestration layer, IDE, or custom tooling. It expects structured input describing your current connection pool configuration, the surrounding infrastructure context, and the specific resilience dimensions you need to audit. The output is a structured audit report, not freeform advice, making it suitable for automated processing, CI/CD integration, or architecture review checklists.

codeCopy
You are a senior reliability engineer auditing a database or service connection pool configuration for resilience gaps.

Analyze the provided [POOL_CONFIGURATION] against the [RESILIENCE_REQUIREMENTS] and [INFRASTRUCTURE_CONTEXT].

Produce a structured audit report using the exact [OUTPUT_SCHEMA] below. For each finding, cite the specific configuration parameter or metric that supports the assessment.

[POOL_CONFIGURATION]:
- Pool Type: [POOL_TYPE, e.g., HikariCP, PgBouncer, r2d2]
- Max Pool Size: [MAX_SIZE]
- Min Idle Connections: [MIN_IDLE]
- Connection Timeout (ms): [CONNECTION_TIMEOUT]
- Idle Timeout (ms): [IDLE_TIMEOUT]
- Max Lifetime (ms): [MAX_LIFETIME]
- Leak Detection Threshold (ms): [LEAK_DETECTION_THRESHOLD]
- Validation Query: [VALIDATION_QUERY]
- Validation Timeout (ms): [VALIDATION_TIMEOUT]
- Connection Acquisition Increment: [ACQUISITION_INCREMENT]
- Target Database/Service: [TARGET_SYSTEM]
- Expected Peak Concurrent Requests: [PEAK_CONCURRENCY]
- Average Request Latency (ms): [AVG_LATENCY]

[RESILIENCE_REQUIREMENTS]:
- Required Availability: [AVAILABILITY_TARGET, e.g., 99.95%]
- Acceptable Degradation Mode: [DEGRADATION_MODE, e.g., queue-and-wait, fast-fail, read-only-fallback]
- Connection Storm Tolerance: [STORM_TOLERANCE, e.g., handle 3x peak for 30s]
- Slow Query Tolerance (ms): [SLOW_QUERY_THRESHOLD]
- Upstream Circuit Breaker: [CIRCUIT_BREAKER_CONFIG, or 'none']

[INFRASTRUCTURE_CONTEXT]:
- Database Max Connections: [DB_MAX_CONNECTIONS]
- Number of Application Instances: [INSTANCE_COUNT]
- Connection Pool per Instance: [POOLS_PER_INSTANCE]
- Network Topology: [TOPOLOGY, e.g., same-VPC, cross-region, multi-AZ]
- Connection Pool Proxy/Load Balancer: [PROXY_DETAILS, or 'none']

[OUTPUT_SCHEMA]:
{
  "audit_summary": {
    "overall_risk": "low|medium|high|critical",
    "critical_findings_count": <integer>,
    "warning_findings_count": <integer>
  },
  "findings": [
    {
      "id": "POOL-<NNN>",
      "severity": "critical|warning|info",
      "category": "sizing|timeout|leak-detection|validation|storm-readiness|saturation|coordination",
      "title": "<concise finding title>",
      "current_state": "<what the configuration currently specifies>",
      "risk": "<what failure mode this creates>",
      "recommendation": "<specific configuration change or architectural fix>",
      "evidence": "<specific parameter values or calculations that support this finding>"
    }
  ],
  "test_scenarios": [
    {
      "scenario": "<name, e.g., Connection Storm, Slow Query Saturation>",
      "expected_behavior": "<how the pool should behave under this scenario>",
      "current_expected_behavior": "<how the current configuration would likely behave>",
      "gap": "<difference between expected and current, or 'none'>"
    }
  ],
  "saturation_analysis": {
    "max_theoretical_connections": <integer>,
    "database_connection_limit": <integer>,
    "headroom_percentage": <integer>,
    "storm_surge_connections": <integer>,
    "exhaustion_risk": "low|medium|high|critical"
  }
}

[CONSTRAINTS]:
- Base every finding on the provided configuration values, not assumptions.
- If a parameter is not provided, note it as missing and flag the risk of unknown defaults.
- Do not recommend changes that violate the stated [RESILIENCE_REQUIREMENTS].
- For critical findings, explicitly state whether a human architecture review is required before production deployment.

To adapt this template, replace each bracketed placeholder with real values from your connection pool configuration, infrastructure topology, and resilience requirements. If a parameter is not applicable, mark it explicitly as none or not configured rather than omitting it, so the model can flag the gap. The output schema is designed to be parsed by downstream validation tools—ensure your application layer validates the JSON structure, checks that finding IDs are unique, and confirms that overall_risk is consistent with the count of critical findings. For high-risk environments, route the audit output to a human reviewer before applying any recommended configuration changes.

The Connection Pool Resilience Audit Prompt is designed to operate as a gated review step in a CI/CD pipeline or a scheduled reliability scan. It expects a structured configuration payload—typically extracted from application configs, infrastructure-as-code templates, or live connection pool metrics—and returns a machine-readable audit report. The harness should treat the LLM call as an untrusted analysis step: the model identifies risks and suggests remediations, but the output must be validated, scored, and potentially routed for human approval before any automated remediation is triggered.

To integrate this prompt into an application, build a pre-processing adapter that normalizes pool configuration from your source of truth (e.g., HikariCP settings, pgbouncer.ini, sequelize options, or cloud-managed pool parameters) into the [POOL_CONFIG] placeholder. The adapter must extract: pool size (min/max), connection timeout, idle timeout, max lifetime, leak detection threshold, and validation query. If any field is missing, inject an explicit "not configured" value rather than omitting it—this prevents the model from hallucinating defaults. Post-processing must parse the JSON output and run a structural validator that checks for required fields (findings, severity, recommendation, test_scenario) and rejects malformed responses. On validation failure, retry once with a repair prompt that includes the raw output and the schema violation error. If the retry also fails, log the failure and escalate to a human reviewer with the original config attached.

For high-risk environments (production databases, payment systems), add a severity gate: if any finding has a severity of critical or high, route the audit to a human SRE for approval before merging or applying changes. The harness should also maintain an audit log that captures the input config, the raw model output, the validated report, and any human overrides. This log serves as evidence for compliance reviews and post-incident analysis. When wiring this into a scheduled scan, set a minimum interval (e.g., weekly) and trigger on config changes detected via git diff or infrastructure state drift. Avoid running the audit on every commit to connection pool configs without debouncing—pool tuning is infrequent, and excessive LLM calls add cost without proportional safety gain.

Model choice matters: use a model with strong JSON-following behavior and low hallucination on structured technical analysis, such as gpt-4o or claude-3.5-sonnet. Avoid smaller or older models that may invent pool parameters or misclassify severity. Set temperature to 0 or a very low value (≤0.1) to maximize output determinism. If your infrastructure uses a model gateway, configure fallback routing to a second provider if the primary model returns a malformed response or times out. The prompt does not require tool use or RAG for standard audits, but if your organization maintains an internal resilience pattern catalog, you can inject relevant pattern documentation into the [CONTEXT] placeholder to ground recommendations in your team's approved practices.

Finally, treat this prompt as a signal, not a decision. The harness should never auto-apply pool configuration changes based solely on model output. Always require explicit human confirmation for production changes, and pair the audit with load-test evidence before adjusting pool sizes or timeouts. The most common production failure mode is not a bad prompt response—it's an engineer blindly applying a model's recommendation without validating it against actual traffic patterns and database capacity.