Design and Architecture of the Vivo App Store Recommendation System

This article introduces how the Vivo App Store recommendation system is designed to efficiently support personalized recommendation scenarios.

Background: The app store’s data originates from various channels (operations schedule, CPD, games, algorithms). After the recommendation project was launched, the data sources remained unchanged; the recommendation system now handles integration with these sources, while the store backend only needs to interact with the recommendation system.

Challenges: The system must provide high performance, high availability, and robust monitoring, while also efficiently supporting multiple concurrent personalized recommendation requests. Requirements include handling three to four parallel demands, delivering a new feature within two days, limiting bugs to fewer than two per scenario, and quickly responding to product team requests.

Typical Recommendation Flow (case example):

If the main app A is an application, retrieve queue Q1 from data source x1 and queue Q2 from data source x2.

Use Q2 to truncate Q1, then intersect the queues, apply developer‑level and category filters, and fallback to Q2 if the intersection is empty.

Select elements at positions n1 and n2 from the intersected queue as the result.

If no data is found, fall back to a big‑data table to fetch the highest‑click‑rate items within the same category, applying developer‑level filtering.

A similar but simplified flow is described for game‑type main apps.

Solution Overview (Section 3):

The author abstracts the business process into several layers:

Plugin Layer: Scene‑specific plugins implement personalized recommendation logic.

Framework Layer: Defines the core recommendation workflow and invokes plugin callbacks.

Protocol Adaptation Layer: Maps scene requirements to appropriate data‑source services.

Data‑Source Service Layer: Wraps RPC calls to various queue providers.

Atomic Service Layer: Provides fine‑grained filtering services (e.g., same‑developer filter).

Base Service Layer: Offers relevance checks based on developer, primary/secondary categories, app type, etc.

The design emphasizes modularity, allowing each layer to be developed, tested, and upgraded independently.

Key Design Patterns Used:

Template Method – structures the process of obtaining raw recommendation queues.

Strategy – selects different data‑source services based on the scenario.

Composite – enables combining multiple atomic services for flexible filtering.

Hot‑Plug Architecture: Java SPI is employed so that each scene’s plugin resides in its own JAR, minimizing intrusion into the framework and base services.

Benefits:

Framework logic is fully abstracted; most scenes require only lightweight plugin callbacks or configuration, achieving up to 30% of scenes with zero code development.

Scenes are isolated, allowing incremental upgrades by updating only the affected plugin or module.

Development effort for personalized recommendation scenarios decreased by ~75%, and bug rates dropped significantly.

Overall, the recommendation system’s architecture shifts the focus of development to scene plugins, reducing duplication, improving maintainability, and supporting rapid personalization.