docs: explain why the matchmaking control plane is Go, fix stale status

Add a Go-vs-C#/Rust/C++ rationale for the matchmaking control plane to
TECH_STACK.md, and point at it from MATCHMAKING.md and README.md.

Also correct CLAUDE.md and README.md, which still described the backend
as unstarted/not built even though server/ has ~13k lines of Go across
matcher, allocator, api, store, security, supervisor and agones.
This commit is contained in:
Josh Creek
2026-09-04 19:10:09 +01:00
parent ad9289fb21
commit de263f30e8
4 changed files with 58 additions and 8 deletions
+5 -1
View File
@@ -29,7 +29,11 @@ Locked constraints:
SDR. Direct ENet remains first-class for local development, CI, LAN,
self-hosting, and community servers.
- The control plane is Go, PostgreSQL, and Redis, deployed on Kubernetes.
Agones owns game-server allocation and lifecycle.
Agones owns game-server allocation and lifecycle. Go is chosen for the
Agones/Kubernetes-native client ecosystem and its concurrency model, not
for raw speed — the control plane never touches a simulation packet. See
"Matchmaking control plane" in [`TECH_STACK.md`](TECH_STACK.md) for the
full rationale and the alternatives weighed.
- Infrastructure is provider-portable. Provider-specific cluster, network,
DNS, and secret-store configuration lives behind isolated deployment
overlays; application code never calls a provider allocation API.