Why Microservices May Not Fit Real‑Time Game Servers

Background Introduction

Recently I interviewed at a listed game company and asked whether they considered adopting a microservice architecture.

The interviewer was surprised, saying they had never heard of microservices and asked for an explanation.

I described benefits such as easier testing, maintenance, upgrades, loose coupling, multi-language development, and auto-scaling.

He replied that game servers need real‑time performance, and microservices would hurt efficiency; modular development is sufficient.

I wondered whether microservices are still a trend, especially for large companies where game services could be split.

Answer

Here are several insightful responses.

Answer by Chen Hongji

In MOBA games like Honor of Kings or League of Legends, systems such as account, rune, hero, skin, friend, and messaging can be large‑scale and may benefit from microservices.

However, the core of a MOBA is high‑speed, low‑latency communication among a small group of players (e.g., 10). Adding even 10 ms latency is unacceptable.

Microservices split a monolithic process into separate services, introducing extra network overhead and complexity (service mesh, gateways, sidecars), which harms latency.

Microservices primarily use request/response patterns and are stateless, making streaming and stateful interactions difficult.

Real‑time games often keep all player communication on a single server to maximize performance and require sticky routing; microservice statelessness conflicts with this.

Game sessions maintain extensive state (tower health, kills, etc.) in memory for the duration of the match; persisting this state externally adds latency.

Therefore, unless you move all state to something like Redis and tolerate additional remote calls, microservices are not suitable for such real‑time games.

Game servers prioritize network, memory, and CPU optimization, avoiding RPC calls and preferring pre‑loaded data.

Microservices are not a silver bullet; they excel for CRUD‑oriented web applications but do not address the high‑performance, state‑heavy nature of game servers.

Answer by an Anonymous User

Microservices make sense when a service is maintained by three or more engineers; otherwise they add unnecessary complexity.

They rely on HTTP, which incurs performance overhead compared to monolithic designs, and handling data consistency across services is painful.

They are popular in web scenarios with many engineers and less stringent real‑time requirements.

Blindly adopting microservices without considering business needs leads to over‑engineering.

Answer by liulilte

Game servers are highly stateful; moving components to separate services introduces network latency and reliability concerns, especially when connections drop.

Cross‑machine RPC calls are unreliable and add timeout complexities.

Asynchronous programming for real‑time gameplay is difficult and increases development effort.