Evolving a Top E‑commerce Recommendation Engine: From V1.0 to V3.0

1. Introduction

Recommendation has become a core competitive factor for e‑commerce platforms, driving traffic and improving user experience across many entry points such as home pages, product detail pages, carts, order‑success pages, and error pages. A robust recommendation system benefits users by delivering relevant items and benefits businesses by mitigating long‑tail effects, increasing user stickiness, and boosting revenue.

2. Recommendation Framework V1.0

V1.0 adopted a simple strategy‑plus‑factory design that allowed rapid iteration when the recommendation project first launched. However, several critical issues emerged:

All business lines shared a single recommendation service, leading to poor fault isolation, resource contention, and limited scalability.

As business grew, the monolithic strategy‑factory pattern hindered development efficiency and could not accommodate stage‑specific logic.

Recall relied on direct Redis connections, creating a bottleneck for data retrieval under tight latency constraints.

All data were stored in a single Redis cluster; high‑traffic business could impact other services, and the cluster’s risk grew with data volume.

3. Recommendation Framework V2.0

V2.0 introduced vertical splitting by business scenario and horizontal division of the recommendation pipeline into distinct stages. This modularization improved fault isolation, allowed independent scaling of each service, and made resource allocation more efficient. Redis remained a core component, but the large cluster was partitioned into multiple smaller clusters to distribute load and reduce single‑point‑of‑failure risk.

Key architectural changes:

Vertical business splitting: each business scenario runs in its own application and storage instance.

Pipeline modularization: stages such as recall, filtering, coarse ranking, merging, fine ranking, intervention, and shuffling are defined as separate modules.

Configuration‑driven pipeline: a pipeline scheduler reads a configuration file to assemble and execute the appropriate sequence of modules for a given scenario.

While V2.0 solved many development‑efficiency and stability problems, it still required substantial code changes for experiments, feature tweaks, or adding new recall paths, limiting rapid iteration.

4. Recommendation Framework V3.0

V3.0 focuses on dynamic configuration and service‑oriented decomposition:

Configuration Service (Server & Client) : a central service that stores pipeline configurations, AB‑test definitions, and experiment parameters. The server exposes RPC interfaces for heartbeat, version checking, and configuration retrieval. The client periodically polls the server, validates version compatibility, and updates local configuration before handling user requests.

Pipeline Dynamic Configuration : the pipeline can be reconfigured at runtime without redeploying code. Handlers (pipeline nodes) can be enabled/disabled based on AB‑test flags, allowing fine‑grained experimentation with minimal code changes.

Recall Service : a dedicated recall service aggregates a full‑catalog recall pool stored in Elasticsearch, synchronizes product updates via MQ, and serves recall results to downstream modules.

Prediction Service : model prediction is exposed as a separate service supporting multiple model versions and ranking strategies, improving performance, scalability, and the ability to switch models on‑the‑fly.

These changes decouple business logic from infrastructure, reduce coupling, and enable rapid, low‑cost iteration.

4.1 Configuration Service Architecture

The service consists of two parts:

Server : manages external RPC interfaces, stores all valid configurations, and assembles configuration payloads for clients.

Client : pulls configuration updates, validates them, and applies them to the local pipeline execution engine.

When a client receives a request, it selects the appropriate pipeline based on the request’s attributes (device model, location, context, experiment info), assembles the handler chain, and executes it to produce recommendation results.

4.2 AB‑Test Capability

AB‑testing is integrated at the handler level. Each handler can be configured with AB‑test rules, allowing the system to enable or disable specific business logic dynamically. This reduces code churn and deployment frequency while supporting real‑time strategy adjustments.

4.3 Recall Service Design

The recall service builds a unified product recall pool in Elasticsearch, ingesting product updates from the core product system via MQ. This central pool eliminates per‑business point‑to‑point development and ensures that real‑time product attributes (price, stock status, etc.) are reflected in recall results.

4.4 Prediction Service Design

Prediction is offered as a stateless service that can host multiple model versions and ranking algorithms. Configuration determines which model to use for a given scenario, enabling on‑demand model upgrades and A/B comparisons without service disruption.

5. Outlook

The framework has progressed from a monolithic V1.0 to a highly modular, dynamically configurable V3.0 capable of supporting fine‑grained personalization and rapid experimentation. Future work includes building an explanation platform for recommendations and enhancing real‑time feature pipelines to achieve truly individualized, explainable recommendations.