Why Game Servers Avoid Microservices: Real‑Time Performance Challenges

Background Introduction

The author recently interviewed at a large listed game company and asked whether they planned to adopt a microservice architecture. The interviewee was surprised, having never heard of microservices, and the author briefly described benefits such as easier testing, maintenance, upgrades, loose coupling, multi‑language development, and auto‑scaling.

The interviewee replied that game servers do not need microservices because they require real‑time performance, and a microservice approach would affect efficiency; modular development is sufficient.

hongjic93's answer

For MOBA games like Honor of Kings or League of Legends, core systems such as account, rune, hero, skin, friends, and messaging can be built with microservices if traffic is large enough, but the core of the game is high‑speed, low‑latency network communication among a small group of players.

Microservices increase network overhead significantly, especially with service meshes, gateways, proxies, and sidecars, which adds latency that players cannot tolerate.

Microservices typically follow a request/response model and are stateless, making them unsuitable for the streaming, stateful communication required by real‑time games.

Game servers often keep all session data in memory to minimize latency, using sticky routing so a player’s packets stay on the same server; this stateful design conflicts with the stateless nature of microservices.

Each game match maintains long‑lived state (e.g., tower health, player kills) that persists for the duration of the match, requiring in‑memory storage and making remote calls to external services undesirable due to added latency.

Overall, microservices are not a silver bullet for game servers; they excel at CRUD‑oriented applications but do not address the high‑performance, stateful requirements of real‑time games.

brice's answer

In simple board‑game servers, microservices are unnecessary because the game logic is not complex enough to warrant the overhead.

Game logic servers are stateful, keeping data in memory and only occasionally persisting to Redis or MySQL, which is unsuitable for real‑time responsiveness.

Game servers need active push communication, which typical microservice gateways (HTTP‑based) cannot provide; TCP or custom protocols are preferred.

HTTP‑based RPC frameworks like Ribbon or Feign are ill‑suited due to message ordering issues; long‑lived TCP connections (e.g., using Dubbo or Netty) are more appropriate.

Thread models for game servers differ from standard Spring MVC; a single process/thread often drives a fixed number of rooms, making Netty a better fit.

Auto‑scaling in games is handled by dedicated “open server” processes and rate‑limiting tools, not generic microservice scaling.

Game operations rarely use service degradation or circuit breaking; failures must be reported directly to users.

While some peripheral services (e.g., payment) can be microservice‑ified, core game servers benefit more from custom, stateful, high‑performance solutions than from generic microservice frameworks.