Challenges and Design Considerations for Game Server Data Systems

Author Introduction: Han Wei joined NetEase in 1999 as its 30th employee. Over eight years he progressed from programmer to project manager and product director. After four years of entrepreneurship (developing video live‑streaming communities and several web‑games), he joined Tencent Games R&D Public Technology Center in 2011, focusing on core game‑server technologies.

In China's internet ecosystem, games have always been the "cash cow". However, many critical issues in game server development have not been clearly distinguished and therefore lack dedicated treatment. While client‑side game engines (Flash Builder, Cocos2d‑X, Unity, Unreal) are standard, there is a noticeable absence of heavyweight, purpose‑built server‑side frameworks or libraries.

Two core problems dominate game server development: (1) communication with the client, and (2) handling user login and game data. For client communication, developers often adopt generic open‑source components such as Protocol Buffers, Thrift, Jetty, or Node.js, adapting them heavily for game needs. For data handling, common solutions like Memcached, MySQL, or Redis fail to fully satisfy game‑specific requirements, leading teams to create ad‑hoc combinations that rarely achieve a perfect fit. Consequently, game servers are littered with repetitive code for memory management, caching, data synchronization, and persistence—code that each new game rewrites from scratch, resulting in significant waste.

To design a data system that truly fits the "game" domain, we must first understand why existing open‑source projects and team‑built solutions have not achieved a seamless match.

E‑commerce / General Internet Business Data Processing Flow

Memcached, Redis, and MySQL are widely used in typical internet services (forums, news portals, e‑commerce platforms) and perform well for most scenarios. Using e‑commerce as an example, the typical backend workflow for a purchase operation is illustrated below:

The following characteristics can be derived from this flow:

1. Tolerable Latency : Operations have low latency requirements and modest request frequency; a page loading within 5 seconds is acceptable, so multiple inter‑process calls are tolerable.

2. Limited Real‑time Interaction : Most internet services are browser‑based, with little need for instantaneous user‑to‑user interaction.

3. Data Dispersed Across Systems : Data is shared among various business modules, requiring dedicated management to maintain consistency.

4. Broad Data Change Scope : Systems continuously process many data modifications originating from users, editors, merchants, etc.

These traits lead to a design where cache systems and databases are separated by business function, with extensive process isolation being feasible due to the relatively weak latency and interaction demands.

Game Business Data Processing Flow

Massively Multiplayer Online Role‑Playing Games (MMORPGs) represent the most complex and "heavy‑backend" game type, serving as a typical reference for game data processing. Their characteristics differ sharply from general internet services:

1. Latency Sensitive : Players expect real‑time feedback; delays beyond 1 second are unacceptable, and many actions require sub‑50 ms response times. Consequently, game servers often consolidate 70 %+ of functionality into a dedicated GameServer process.

2. Massive Real‑time Interaction : Players continuously see and interact with each other, necessitating centralized online data to enable mutual actions (e.g., combat).

3. Data Centralized : Game data is largely self‑contained and seldom useful outside the game, so it is stored in a single dedicated database without the need for extensive cross‑process sharing.

4. Limited Data Change Volume : Although game data changes rapidly (e.g., HP reduction on hit), the system tolerates a degree of inconsistency. Data falls into two categories: player save files (numerous small records) and game configuration (rarely changed, mostly read‑only).

Problems of General Cache Systems in Games

Cross‑process caches (e.g., Memcached, Redis) cannot meet the ultra‑low latency demands of real‑time combat, where each read/write may take 10‑20 ms per data center hop.

Generic caches and databases struggle to aggregate multiple processes into a cohesive data grid, forcing developers to locate the correct backend process for each player, which adds unnecessary complexity.

General data systems are language‑agnostic and lack direct object storage, leading to massive boiler‑plate code for serializing/deserializing hundreds of game‑specific data structures.

These shortcomings indicate the need for a fundamentally different data system design for games.

Features and Advantages of a Local Distributed Cache Service

Leverages the GameServer process memory for automatic cache management, satisfying strict latency requirements.

Provides automatic data persistence and disaster recovery, allowing the GameServer itself to be a distributed program and improving overall throughput.

Offers excellent programming usability by enabling direct storage of in‑memory objects, eliminating repetitive data‑structure description and saving development time.