[Dejmenek]

Summary

This is the third PR for #165 and it is stacked on #167. It adds load tests for the write paths: creating tournaments, joining them, playing and correcting matches, and generating brackets. The contention tests check that the concurrency handling described in ADRs 0002, 0004 and 0006 holds under load.

Scenarios

• Ten users create open tournaments at 10 requests per second.
• Eight users at a time try to take the two free slots of the same tournament. After the run, no tournament may hold more participants than MaxParticipants.
• Six requests at a time play the same match, and six send different corrections against one stale version. Exactly one request per match may succeed and the rest must return Match.AlreadyPlayed or Match.VersionConflict.
• Brackets are generated for 8, 16 and 32 participants, single elimination and round robin. Each tournament gets two calls, so the second must return Bracket.AlreadyExists.

Expected rejections count as OK responses with their domain code, so they do not use up the error budget. The contention tests also compare the number of successful requests with what ended up in the database.

Helpers

WriteScenarioProvisioner creates users, tournaments and matches through DbContext before the measured run, so the loop only exercises the mutation under test. Baselines for the new steps are the worst values from three runs, because run to run variance on this machine is large.

Fix to the scenario results

While checking the new numbers I found that scenario level status codes were doubled. Returning a step's Response from the scenario delegate makes NBomber count its status code and payload a second time. I confirmed this with a small probe outside the suite. Scenarios now go through GraphQLLoadScenario.Create, which returns a plain Ok or Fail from the last step, so a failing step still counts against the error budget. The status mix check also takes both sides of its ratio from status code counts. The older load tests are switched over too.

Things worth knowing

• Losers of a slot race get Tournament.Full even when slots remain, as ADR 0004 describes. Only about 90 of roughly 150 free slots get filled in the join test.
• The match tests run without warm-up, because NBomber warm-up runs the mutations but leaves them out of the stats.
• Contenders are arrivals from an open model, about 25 ms apart, not perfectly simultaneous requests.
• In one full suite run the authentication test failed on logout latency, then passed on its own with numbers better than its baseline. I read that as noise from a long back to back run and left its baselines alone.

Testing

All 15 load tests passed, apart from the one authentication run mentioned above. Unit tests (160) and integration tests (252) pass locally. This PR only changes the load test project, and CI runs the unit and integration tests. The load tests need Docker and run manually with dotnet test TournamentAPI.LoadTests --filter "Category=Load".

Part of #165.

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

🤖 Generated with Claude Code