User Need

As a GOV.UK platform engineer
I want a repeatable way to trigger our rate-limiting VCL snippet in integration
so that I can prove the 829 → 429 Too Many Requests transformation works before we ship it to production

What’s Needed

• Design at least one deterministic trigger method for obj.status == 829, e.g.
  • Header-based switch: send X-Force-Rate-Limit: true from client → origin echoes status 829.
  • Synthetic endpoint: a dedicated /simulate-rate-limit path in origin app that always returns 829.
  • Load-test harness: bombard any endpoint until origin’s rate-limit logic emits 829.
• Implement the chosen trigger (keep code and infra changes behind an “integration-only” guard).
• Write a script (cURL, k6, or Locust) that:
  1. Calls the endpoint
  2. Asserts the edge response is HTTP 429 with the correct HTML body
  3. Fails if any 5xx or wrong status is returned
• Document the trigger + test steps in our Google Drive.
• Provide an effort estimate to convert the spike into a productionised test in our CI pipeline.

Acceptance Criteria

• Everything in What’s Needed is delivered.
• Running make test-fastly-rate-limit (or equivalent) in integration returns exit 0 after validating a 429 page.
• Spike document reviewed and merged; link added to the runbook.

User Comms Plan (if applicable)

Post a short demo (GIF or screenshot) and link to the spike doc in #govuk-platform-engineering.

Assumptions (optional)

• Creating new endpoints or headers in the integration origin is low-risk and does not propagate to production.
• Fastly contract allows unlimited config changes in the integration service.

Risks & Mitigation (optional)

Notes

• Original incident Slack thread: https://gds.slack.com/archives/CAH9L36LR/p1748607279299109
• Feel free to bring this up at the monthly Fastly account management meeting.