How We Evolved Our Recommendation Engine: From V1.0 to V3.0 Architecture

1. Introduction

Recommendation has become the core competitive advantage for e‑commerce platforms, serving as a major traffic entry point across many pages such as home, detail, cart, order success, and error pages. It greatly enhances user experience and business value by addressing long‑tail and Matthew effects.

2. Recommendation Framework V.1.0

2.1 Framework Prototype

At the start, a simple strategy‑plus‑factory design was adopted to expose recommendation algorithms via API, enabling rapid business iteration.

2.2 Existing Problems

A single recommendation service supporting all upstream businesses leads to poor fault isolation, resource contention, and limited scalability; scaling must be done for the whole application.

Rapid business growth increases system complexity; the simple strategy‑factory pattern becomes a development bottleneck, requiring stage‑based modularization.

Recall bottleneck caused by direct Redis connections limits performance and prevents abstraction of high‑similarity product pools.

All data stored in a single Redis cluster causes high‑concurrency pressure; while horizontal sharding can relieve immediate load, growing data volume increases the risk of cluster failure.

3. Recommendation Framework V.2.0

To address the risks of V1.0, the system was vertically split per business and horizontally split per recommendation stage, achieving better isolation, resource allocation, and scalability. Configuration files define the pipeline (recall, filter, coarse ranking, merge, fine ranking, intervention, shuffle, etc.).

Pipeline scheduling design is illustrated below.

4. Recommendation Framework V.3.0

Version 3.0 focuses on dynamic pipeline configuration, separating compute‑intensive model prediction and IO‑intensive recall into independent services, and introducing a configuration service that manages client‑server interactions.

The client maintains a heartbeat with the server, pulls the latest configuration, validates versions, and executes the configured handler chain during user requests.

The server provides RPC interfaces for heartbeat responses and configuration queries, and stores configuration centrally.

5. Outlook

Future work will focus on finer‑grained operation, building an explanation platform, and integrating real‑time features to achieve personalized, per‑user recommendations and improve traffic efficiency.