Why Game Servers Resist Microservices: Real‑Time Constraints Explained

Background

During an interview with a listed game company, the question was whether the company plans to adopt a microservice architecture. The interviewee noted that real‑time game servers have strict latency and state requirements that conflict with typical microservice designs.

Key technical reasons microservices are unsuitable for core real‑time game servers

Core gameplay (e.g., MOBA) requires bi‑directional, low‑latency communication among ~10 players. A delay of >10 ms is noticeable.

Microservice decomposition adds extra network hops, service mesh, gateways, and sidecars, increasing round‑trip latency.

Typical microservice APIs are request/response and stateless, while game sessions need persistent in‑memory state and streaming (pub/sub, multicast).

Game servers usually run a single process that handles all players of a match, keeping data local to minimise latency. This requires sticky routing, which contradicts the stateless scaling model of microservices.

Each match is an isolated sandbox with long‑lived state (tower health, player kills, etc.) that persists only in memory until the match ends. Moving this state to external stores such as Redis would introduce remote calls and additional latency.

Push‑based communication (TCP, custom binary protocols) is essential; HTTP‑based microservice gateways cannot efficiently handle TCP/WebSocket traffic.

Ordering guarantees are critical. HTTP‑based RPC frameworks (Ribbon, Feign) can reorder messages, whereas long‑lived TCP connections (e.g., Dubbo) preserve order.

Game server thread models differ from typical Spring MVC; they often use Netty with a single‑process/thread model driving a fixed number of rooms, avoiding heavyweight thread pools.

Auto‑scaling in games (“opening servers”) follows predefined processes and does not rely on dynamic microservice scaling.

Service degradation and circuit‑breaker patterns are rarely used; failures must be reported directly to users.

Components that may still benefit from microservice decomposition

Peripheral services such as account management, payment/recharge, matchmaking lobby, and analytics can be built as independent services because they are relatively simple CRUD‑oriented workloads.

These peripheral services can use standard horizontal scaling, service discovery, and container orchestration without affecting the core game loop.

Typical architecture for a real‑time game server

// Simplified flow for a MOBA match
1. Client connects via TCP to a dedicated game server instance.
2. Server maintains all match state in memory (player positions, health, events).
3. Server processes incoming events (e.g., skill cast) and broadcasts updates to all participants using a low‑latency publish/subscribe channel.
4. No external RPC calls during the match; optional periodic snapshots may be persisted to Redis for crash recovery.
5. After match ends, server clears in‑memory state.

Conclusion

Microservices excel for stateless, CRUD‑heavy applications but are a poor fit for the stateful, ultra‑low‑latency core of real‑time game servers. A monolithic or tightly‑coupled process model, often built on Netty with long‑lived TCP connections, remains the preferred architecture, while peripheral services can be decomposed into microservices where appropriate.