Realtime multiplayer gaming

Архитектура разделяет control plane и match data plane. Login, lobby, matchmaking и recovery используют надёжные API. После allocation клиент подключается к конкретному региональному dedicated server и передаёт sequenced commands. Server остаётся authoritative: клиент предсказывает UX, но не решает исход симуляции.

Anycast — не latency fan-out

Anycast address маршрутизируется к одному из доступных узлов по решению сети. Он удобен для control-plane discovery и DDoS surface, но один anycast request не «пингует 20 PoP» и не измеряет все регионы.

Корректный выбор региона:

1. client обращается к anycast control endpoint;
2. locator возвращает небольшой набор healthy signed unicast probe endpoints;
3. client измеряет 2–3 кандидата с bounded timeout;
4. matchmaking учитывает party, skill, queue time и измеренную network quality;
5. allocator выдаёт signed unicast game endpoint.

Internet routing не гарантирует географически ближайший PoP или заданный RTT. Latency threshold — SLO/queue policy: при нехватке игроков или capacity продукт может ждать, с согласия расширить region либо завершить запрос retryable error.

Match allocation

Warm Fleet содержит конечное число Ready GameServers. Allocation выбирает один экземпляр и записывает session/reconnect metadata. Утверждение «server появляется мгновенно» неверно: warm buffer снижает latency, но может быть исчерпан.

Fleet autoscaling следит за Ready buffer, allocation failure, queue depth и startup time. При exhaustion нельзя вернуть несуществующий endpoint. Canary и rolling update не уничтожают Allocated server до корректного shutdown.