A single-GPU KataGo process is a hard concurrency bottleneck — pool it server-side, do not let clients hit it directly

Running one KataGo analysis process (one GPU) behind a WebSocket bridge works for single-player, but it does NOT scale to concurrent access. Firing several concurrent createAI/estimate/suggest calls at it (e.g. from browser devtools while debugging, or many clients) saturates its single inference queue: new WS connects/queries stall, and in the browser the tab renderer freezes (CDP Runtime.evaluate times out) because a client-side genMove also runs on the main thread. Lessons for a multi-user Go/AI app: (1) never let each client open its own connection and fire engine queries freely; route ALL engine access through ONE server-side bounded PRIORITY queue with small max-in-flight (1-2), priority tiers (live bot move > hint > post-game analysis), per-request visit caps that degrade under load, request coalescing for identical positions, and cancellation on disconnect. (2) Keep a pure-JS fallback engine (Monte-Carlo, time-capped, in a Worker) for when the GPU engine is down or overloaded. (3) When debugging, don not spam the single engine with concurrent probes — you will DoS your own bridge. This bottleneck is the main thing that shapes the backend architecture for 10-30 concurrent users.