Why Game Server Developers Are Reluctant to Adopt Microservices

Background: The author interviewed a listed game company and asked whether they planned to adopt microservice architecture. The interviewee had never heard of microservices and needed an explanation.

Response from hongjic93: While non‑core systems like account, rune, hero, skin, and friend services could be built as microservices, the core of a MOBA game relies on ultra‑low‑latency, high‑speed communication among a small group of players (e.g., 10 players). Adding network hops, service meshes, gateways, or sidecars would increase latency, which is unacceptable for real‑time gameplay.

Microservices are typically request/response and stateless, which conflicts with the stateful streaming nature of game sessions. Games often keep all player state in memory on a single server to minimize latency and use sticky routing so that a player’s connection remains on the same server for the duration of a match. Stateless scaling and load‑balancing mechanisms of microservices oppose this requirement.

Each match can be seen as an isolated sandbox with long‑lived state (tower health, player kills, etc.) that persists until the game ends. Even if this state is not persisted to a database, it must remain in memory, making remote calls to external services (e.g., Redis) introduce additional latency.

In summary, the high demands on network, memory, and CPU performance, combined with the need for stateful, low‑latency communication, make traditional microservice approaches unsuitable for fast‑paced multiplayer games.

Response from brice (chess‑type games): Similar arguments apply: game logic is not complex enough to warrant microservices; servers must be stateful and handle real‑time TCP connections, which HTTP‑based microservice gateways cannot satisfy. Long‑living connections, ordered message delivery, and custom protocols (e.g., Netty, Dubbo) are preferred over HTTP/REST. Scaling is handled by game‑specific “open‑server” processes rather than generic auto‑scaling mechanisms.

Both answers conclude that while certain peripheral services (e.g., payment, login) might be micro‑service‑ified, the core game server architecture remains monolithic or tightly coupled to meet real‑time performance requirements.