Why Game Servers Shun Microservices: Real‑Time Performance Challenges

Background

During an interview with a listed game company, the author asked whether the company planned to adopt a micro‑service architecture. The interviewee was unfamiliar with micro‑services and the author explained benefits such as easier testing, maintenance, loose coupling, multi‑language support, and auto‑scaling.

The interviewee replied that game servers need real‑time performance, and micro‑services would hurt efficiency, so a modular monolith is sufficient.

Answer by hongjic93

In MOBA games like Honor of Kings or League of Legends, many subsystems (account, rune, hero, skin, friends, messaging) could be built with micro‑services if traffic is high, but they are not the core.

The core is the fast, low‑latency communication among a small group of players (typically ten). Adding even 10 ms latency is unacceptable.

Micro‑services split a monolithic process into separate services, introducing additional network overhead and complexity (service mesh, gateways, sidecars) that conflicts with the strict latency requirements.

Micro‑services are usually request/response and stateless, making them unsuitable for the stateful streaming communication required by games.

Games often keep all player‑session state in memory on a single server to avoid cross‑server latency; this requires sticky routing, which contradicts the stateless nature of typical micro‑services.

Each match runs as an isolated sandbox with long‑lived state (tower health, kills, etc.) that persists for the duration of the game, so the state cannot be off‑loaded to remote storage without incurring latency.

Therefore, micro‑services are not a silver bullet for game servers; the high‑performance, stateful, streaming nature of games makes a monolithic or tightly‑coupled design more appropriate.

Answer by brice

From experience with simple board‑game servers, several points emerge:

Micro‑services address complex business logic; game logic is relatively simple and can be handled within a single process.

Game servers must be stateful and keep most data in memory; persistent stores like Redis or MySQL are used only for occasional asynchronous persistence.

Games require proactive push communication; traditional HTTP gateways cannot satisfy the low‑latency TCP needs.

RPC frameworks based on HTTP (Ribbon, Feign) are unsuitable due to message ordering issues; long‑lived TCP connections (e.g., Dubbo, Netty) are preferred.

The threading model of game servers differs from typical Spring MVC; a single‑process/thread model driving a fixed number of rooms is common.

Auto‑scaling in games is called “opening servers” and follows established procedures.

Service degradation and circuit breaking are rarely used; failures are reported directly to users.

Only peripheral services (e.g., login, payment) might benefit from micro‑service patterns, but the core match server usually does not.

Even when using Spring Cloud, additional support for WebFlux, long‑lived connections, and protobuf‑based RPC would be required.