Emergency Public Benefit Influx Load Testing Matrix

Role: Government Digital Service (GDS) Performance & Stress Test Architect.

Context

• Public Entity: {{public_entity}}
• Program Name: {{benefit_program_name}}
• Concurrency Target: {{peak_concurrency_target}}
• Legacy Dependencies: {{legacy_backend_dependencies}}
• Failure Threshold SLAs: {{failure_threshold_slas}}
• Hosting Infrastructure: {{deployment_infrastructure}}

Task

Design a multi-tiered Performance & Fault-Tolerance Test Matrix to evaluate {{benefit_program_name}} during extreme public application surges, isolating system limits before live launch.

Method

1. Deconstruct user transaction paths into compute-heavy, DB-intensive, and third-party bound operations.
2. Model gradual ramp-up, sustained peak, and spike traffic patterns reaching {{peak_concurrency_target}}.
3. Identify choke points where {{legacy_backend_dependencies}} could trigger cascading thread-pool exhaustion.
4. Define performance metrics (p95 latency, throughput, error rates) constrained by {{failure_threshold_slas}}.
5. Design chaos injection vectors (database node failover, rate-limit tripping, queue throttling) on {{deployment_infrastructure}}.
6. Formulate synthetic traffic profiles mimicking simultaneous citizen submission behaviors.
7. Populate a load testing matrix specifying simulation parameters, telemetry targets, and degrade/fallback triggers.

Constraints

• You MUST specify measurable telemetry metrics (e.g., p95 response time, CPU saturation, TPS) for every test stage.
• You MUST NOT assume infinite elastic scaling without validating {{legacy_backend_dependencies}} throughput caps.
• Every stress scenario MUST define a graceful degradation protocol (e.g., virtual waiting rooms, queue shedding).
• Test scenarios must address both client-side experience and database write-locking.

Output format

Generate the output in three distinct sections:

1. Surge Profile Architecture (Summary under 150 words describing traffic distribution).
2. Load & Chaos Test Matrix (Markdown table with columns: Test Stage, Virtual Users [VUs], Injection Type, Target Subsystem, Target SLA, Pass Criteria, Failure Mode / Degrade Action).
3. Capacity Bottleneck Contingency Guide (4-5 actionable mitigation recipes for developers).

Self-review

• Ensure all 6 input variables are accurately integrated into the test design.
• Confirm the matrix includes baseline, peak, spike, soak, and chaos injection test stages.
• Verify all SLA criteria are directly measurable against {{failure_threshold_slas}}.