Why Game Companies’ Servers Are Reluctant to Adopt Microservices

During a recent interview with a large listed game company, the author asked whether the studio planned to adopt microservice architecture. The interviewee was surprised, having never heard of microservices, prompting a discussion of the perceived benefits and drawbacks.

hongjic93's response notes that while peripheral systems such as accounts, skins, friends, and messaging could be split into microservices, the core of a MOBA game relies on ultra‑low‑latency, high‑frequency, multi‑directional communication among a small group of players. Microservices introduce additional network hops, service meshes, gateways, and sidecars, all of which increase latency. Moreover, most microservice frameworks assume stateless request/response interactions, which clash with the stateful, streaming nature of real‑time game sessions that often require sticky routing and long‑lived in‑memory state.

brice's response emphasizes that game logic is not as complex as typical business applications, and therefore does not justify the overhead of microservice decomposition. Game servers must be stateful, use TCP long connections, and push updates instantly; HTTP‑based RPC frameworks (e.g., Ribbon, Feign) can cause message ordering issues. Instead, low‑level networking libraries such as Netty or RPC solutions like Dubbo that support persistent connections are more appropriate. Only peripheral services like login or payment gateways might benefit from microservice patterns, but even then the gains are limited.

The overall conclusion is that microservices are not a silver bullet for game server architecture. The stringent performance, latency, and state requirements of real‑time multiplayer games make the added complexity and overhead of microservices undesirable, unless the game can tolerate the extra network latency and redesign its state management.