Why Game Servers Are Reluctant to Adopt Microservices Architecture

During a recent interview with a listed game company, the author asked whether the studio planned to adopt a microservices architecture. The interviewee, unfamiliar with microservices, was surprised and asked for an explanation.

The author described typical microservice benefits such as easier testing, maintenance, scaling, loose coupling, and language independence. The interviewee replied that game servers need real‑time performance, and microservices would hurt efficiency, so a modular monolithic approach is preferred.

Expert Chen Hongji elaborated that while peripheral systems (account, hero, skin, messaging) could be split into microservices, the core MOBA gameplay relies on ultra‑low‑latency, high‑throughput communication among a small group of players. Adding network hops, service meshes, gateways, or sidecars would increase latency beyond acceptable limits.

He highlighted several technical challenges: microservices introduce extra network overhead; they are typically request/response‑oriented and stateless, which conflicts with the stateful streaming required for real‑time game events; sticky routing is needed to keep a player’s session on the same server, but microservice load‑balancing prefers stateless distribution.

Furthermore, each game match maintains extensive in‑memory state until the match ends, making it impractical to offload this state to external storage without incurring latency penalties.

Brice added that simple board‑game servers also face similar constraints: the game logic is stateful, requires fast TCP connections, and cannot rely on HTTP‑based RPC frameworks like Ribbon or Feign due to ordering issues. Long‑lived connections (e.g., Netty, Dubbo) are more appropriate.

Overall, the consensus is that microservices are not a silver bullet for real‑time game servers; the need for low latency, stateful processing, and specialized networking makes monolithic or tightly coupled designs more suitable for the core gameplay loop.