Why Game Companies' Servers Reluctant to Adopt Microservices

In a recent Zhihu discussion, the author asks why game companies are hesitant to adopt microservice architectures for their servers.

Background

The interviewee, a game company recruiter, initially thought microservices were unnecessary for games because they require real‑time performance, and a monolithic approach can suffice.

Response from hongjic93

Microservices can be used for auxiliary systems such as account, rune, hero, skin, and friend services, especially when traffic is high, but the core of a MOBA game is high‑speed, low‑latency communication among a small group of players.

Microservice decomposition adds significant network overhead, including service mesh, gateways, and sidecars, which can increase latency beyond the acceptable 10 ms threshold.

Most microservice frameworks assume stateless request/response patterns, which are ill‑suited for streaming and stateful game sessions that require persistent in‑memory data.

Game servers often keep all player communication on a single server to minimize latency and rely on sticky routing; breaking this into stateless services would conflict with the need for stateful, low‑latency connections.

Each game instance maintains long‑lived state (e.g., tower health, player kills) in memory for the duration of the match, making it impractical to externalize this state via microservices without incurring additional remote calls.

Overall, microservices are not a silver bullet for game servers; they are more appropriate for CRUD‑oriented applications rather than high‑performance, stateful real‑time games.

Response from brice

For simple games like card games, the business logic is not complex enough to justify microservices; the server is stateful, keeping game state in memory and only persisting occasionally to Redis or MySQL.

Game servers need long‑lived TCP connections for real‑time messaging, which many HTTP‑based microservice gateways cannot provide; solutions like Netty or Dubbo are more suitable.

Horizontal scaling in games is handled by “opening servers” (instance provisioning) rather than dynamic microservice scaling.

Service degradation and circuit breaking are rarely used; failures must be reported directly to the player.

While some peripheral services (e.g., payment) could be micro‑service‑ified, the core game loop remains best served by a tightly coupled, stateful architecture.

Promotional Content

The article also contains extensive promotional material for ChatGPT services, a paid community, and various downloadable resources, which are unrelated to the technical discussion.