Maintaining Game World State with Data Services: Architecture, Sharding, and High Availability

The article starts by distinguishing two parts of game world state—persistent player data and transient scene state—and explains why frequent-access data should reside in memory while less‑frequent data can be handled by an external data service.

It reviews traditional MMO architectures where a DB‑proxy process abstracts storage APIs, highlighting issues such as code duplication, tight coupling of storage and caching, lack of scalability, and single‑point failures.

Redis is introduced as a versatile data‑structure server that can act both as a cache and a primary store; the author describes how a data service built on Redis solves player‑save problems and enables service‑level reuse through generated APIs.

The concept of stateless services is discussed, emphasizing separation of service process lifetime from state lifetime, benefits for scalability, and the need for external state storage, with Redis‑based data services providing that capability.

Sharding strategies are examined, comparing presharding, gossip‑based, and consensus‑based approaches; the article advocates a static presharding combined with client‑side sharding to achieve horizontal scaling without excessive complexity.

High‑availability mechanisms are covered, including Redis replication, Sentinel fail‑over, and a custom watcher service that monitors Redis instances, performs leader election, and coordinates fail‑over, with Zookeeper used for distributed coordination and configuration distribution.

Finally, the author summarizes the overall architecture—static infrastructure components (gate, MQ, Redis, MySQL, Zookeeper) and dynamic custom services—and provides references to open‑source implementations and related tools.