Architecture and Evolution of a Game Recommendation System

The article begins by explaining the need for a game recommendation system, contrasting search (active) with recommendation (passive) and describing how recommendation bridges users with content efficiently, creating business value.

It then outlines the initial model, which consists of four components: operation rule configuration, algorithm model training, recommendation strategy activation, and data collection via telemetry.

As more business scenarios adopt the system, the architecture evolves to handle increased complexity, supporting various scenes (classification, topics, rankings, home page, search) and strategy types (intervention, shuffling, resource allocation, guarantee), leading to challenges in performance, scalability, and availability.

To address these challenges, a generic combination strategy is introduced, featuring acceptor, executor, matcher, listener, and process roles that dynamically assemble strategies based on configuration templates, enabling high reuse and easy extension.

In the high‑traffic environment (≈30k TPS), a multi‑level cache design using Redis and local in‑memory caches ensures read‑heavy workloads remain fast, with configuration updates written to MySQL then Redis, and local caches refreshed lazily.

When node count grew, cache synchronization lag increased, so a version‑based message‑queue mechanism was added to achieve near‑real‑time strategy updates.

Frequent Full GC (FGC) in Java services caused latency spikes; the solution involved moving stable caches off‑heap, reducing unnecessary heap churn, and switching to G1GC with tuned parameters (e.g., -XX:+UseG1GC , -XX:MaxGCPauseMillis=200 , -XX:InitiatingHeapOccupancyPercent=25 , etc.).

Rate limiting and degradation are handled with layered controls (Hystrix, Sentinel, Resilience4j), prioritizing critical services and providing fallback strategies that reuse user history for personalized defaults.

Fine‑grained operation is achieved through a multi‑layer hash orthogonal experiment platform, enabling A/B testing without physical traffic isolation; experiments are defined by hash‑based layer IDs, and results are collected via SDK‑embedded telemetry.

Multi‑path recall combines various recall sources (personalized, algorithmic, game pool, category/tag/subject) to increase candidate coverage, followed by merging, filtering, and ranking.

Dynamic parameter adjustment (dynamic tuning) modifies exposure weights in real time based on online metrics, ensuring optimal balance between revenue and user experience.

Looking ahead, the team plans to build an intelligent, full‑stack support system covering smart coupons, push notifications, and user feedback processing to further enhance platform value.

{
    "code": 0,
    "data": [
        {
            "score": 0.016114970572330977,
            "data": {
                "gameId": 53154,
                "appId": 1364982,
                "recommendReason": null
            },
            "gameps": "埋点信息"
        }
    ],
    "reqId": "20200810174423TBSIowaU52fjwjjz"
}

{
    "reqId": "20200810142134No5UkCibMdAvopoh",
    "scene": "appstore.idx",
    "imei": "869868031396914",
    "experimentInfo": [
        {
            "experimentId": "RECOMMENDATION_SCENE",
            "salt": "RECOMMENDATION_SCENE",
            "imei": "3995823625",
            "sinfo": "策略信息"
        },
        {
            "experimentId": "AUTO_RECOMMENDATION_REASON",
            "salt": "RECOMMENDATION_SCENE",
            "imei": "1140225751",
            "sid": "3，4，5"
        }
    ]
}