Why Game Servers Shy Away from Microservices: Real‑Time Constraints Explained

Background

During a Zhihu interview, the author asked a game company about plans for microservice architecture. The interviewee was surprised, having never heard of microservices, and the author explained typical benefits such as easier testing, maintenance, scaling, loose coupling, multi‑language support, and auto‑scaling.

Why Game Servers Resist Microservices (Answer by hongjic93)

In MOBA games like Honor of Kings or League of Legends, the core is fast, low‑latency communication among a small group of players. Microservices introduce additional network overhead, service mesh, gateways, and sidecars, which increase latency. They also rely on stateless request/response patterns, unsuitable for the stateful, streaming interactions required by real‑time games. Maintaining game state in memory for the duration of a match conflicts with the stateless nature of microservices, and moving state to external stores such as Redis would add remote calls and further latency.

Why Game Servers Resist Microservices (Answer by brice)

For simple game logic (e.g., card games), the business complexity is low, and the server must handle high‑frequency, low‑latency operations, making stateful in‑memory processing essential. TCP long‑connections, custom protocols, or Netty are preferred over HTTP‑based gateways. Traditional RPC frameworks like Ribbon or Feign are unsuitable because of message ordering issues; frameworks supporting long‑lived connections (e.g., Dubbo) are more appropriate. Additionally, automatic scaling in games is handled by dedicated “open‑server” processes rather than generic cloud auto‑scaling, and service discovery, circuit breaking, and graceful degradation are rarely applicable.

Conclusion

Microservices are not a silver bullet for game server architecture. While they help decompose CRUD‑heavy applications, the real‑time, stateful, low‑latency requirements of online games make traditional microservice patterns problematic.