[Dejmenek]

Summary

This is the last PR for #165 and it is stacked on #169. It adds the three long running scenario types from the issue: a spike, a soak and a breakpoint test. It also records the design in a new ADR.

Tests

• The spike test runs a heavy list query at 25 requests per second, jumps to 150 for 10 seconds, drains, and returns to 25. It checks the error budget, tail latency and payload size in each phase, and requires the p95 after the spike to stay within twice the p95 before it. A cheap list query showed a p95 of 22 ms even at 200 requests per second, so it could not stress the API.
• The soak test runs the mixed browsing load for about 12 minutes as a warm up and six two minute segments. Each step is checked against its Medium baseline per segment, and the last segment must not drift past twice the first. Managed memory is sampled after forced collections at the end of the first segment and at the end of the run.
• The breakpoint test steps a heavy query through 25 to 150 requests per second after a warm up, and finds the highest rate whose p95 stays under 800 ms. It measured 125 requests per second in two runs. The test asserts a floor of 50, and a safety abort stops a runaway run without failing the test.

The spike test carries Category=Load. Soak and breakpoint carry Category=Soak only, so the normal load run skips them. dotnet test TournamentAPI.LoadTests --filter "Category=Soak" runs them, and CLAUDE.md documents it.

Helpers and docs

LoadPhases turns named phases into Inject simulations and names each step after the phase running when it starts. LoadThreshold takes an optional abort count for the breakpoint safety abort. ADR 0009 records why the breakpoint is read from per step latency after the run instead of from an abort on errors, and why the soak is one run with named segments. ADR 0008 now lists the headroom rules the budgets use.

Things worth knowing

• The 150 MB memory growth limit in the soak test has not been calibrated against a measured run. It stays as a guess for now.
• The soak passed once. A second run failed on tail latency in a few segments while the machine had many other programs open, so it needs a quiet machine.
• Spike budgets come from the worst of three runs. Run to run variance on this machine is large, and the first phase of any run carries cold start latency, which is why each test has an unasserted warm up.
• Pinning the azure-sql-edge image from the issue's task list is not part of this stack. The image is still on latest on purpose.

Testing

Unit tests (160) and integration tests (252) pass locally. The spike test passed three times and the breakpoint test twice on the final code. This PR only changes the load test project and the docs, and CI runs the unit and integration tests. Load tests need Docker and run manually.

Closes #165.

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

🤖 Generated with Claude Code