Why Microservices May Not Fit Real‑Time Game Server Architecture

Background Introduction

I recently interviewed at a large, publicly listed game company and asked whether they were considering a microservice architecture.

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

I described typical microservice benefits: easier testing, maintenance, upgrades, loose coupling, multi‑language support, and auto‑scaling.

They replied that game servers usually don’t need microservices because real‑time performance would suffer; modular development is sufficient.

Answer

Below are several thoughtful responses that highlight why technology must match the scenario.

Chen Hongji's Answer

In MOBA games like Honor of Kings or League of Legends, many subsystems (account, rune, hero, skin, friends, messaging) could be built as microservices if traffic is high enough.

However, the core of a MOBA is fast, multi‑directional communication among a small group of players, where even a 10 ms delay is unacceptable.

Microservices split a monolithic process into separate services, adding significant network overhead, especially with service meshes, gateways, and sidecars, which increase latency.

Microservices typically follow a request/response model and struggle with streaming; they require stateless services for horizontal scaling, but streaming inherently involves state.

For optimal performance, a single server often handles all communication for a match, enabling local data exchange and sticky routing; microservice statelessness conflicts with this requirement.

Each game match is a sandbox with its own long‑lived state (tower health, kills, etc.) that persists until the match ends, making state management in microservices cumbersome.

Thus, while you could store state in Redis, the added remote requests would increase latency, making microservices unsuitable for real‑time game logic.

Game servers demand extreme optimization of network, memory, and CPU, with minimal RPC calls; any remote data access must be prefetched at game start.

Microservices are not a silver bullet; they are useful for CRUD‑oriented web applications but struggle with high‑performance, stateful real‑time systems.

Anonymous User's Answer

Microservices are justified only when a service is maintained by three or more engineers; otherwise, the overhead outweighs benefits.

They rely heavily on HTTP, which is less performant than monolithic designs, especially for high‑frequency calls and data consistency challenges.

Web‑centric microservices suit scenarios where real‑time performance is not critical.

liulilte's Answer

Game servers are heavily stateful; moving state across network boundaries introduces latency and reliability concerns.

Each microservice call becomes an RPC, which may be unreliable; handling timeouts and retries adds complexity.

Real‑time actions (e.g., skill casting) cannot tolerate the hundreds of milliseconds delay that microservice communication might introduce.

Using coroutines or async programming in C++ can mitigate some issues but increases code complexity and requires more skilled developers.

Conclusion

Choosing an architecture should be driven by the specific business and technical requirements; microservices are not universally applicable, especially for latency‑sensitive game servers where stateful, high‑performance processing is essential.