Design and Implementation of a Real-Time Product Tagging Platform for a Second‑Hand E‑Commerce System

1. Background

Zhuanzhuan, a leading second‑hand e‑commerce platform, faces four major challenges in fine‑grained operations: high complexity of product data, low efficiency of product management and filtering, degraded user experience, and limited operational efficiency.

1.1 Challenges of Fine‑Grained Operations

High complexity of second‑hand product data : besides standard attributes, products have numerous non‑standard attributes such as condition, inspection reports, and these are scattered across descriptions, images, and reports, making standardization difficult.

Low efficiency of product management and filtering : traditional SPU models cannot handle rich non‑standard attributes, hindering precise management and selection.

User experience impact : without effective use of non‑standard attributes, users cannot accurately search for items like “good condition” phones.

Operational efficiency difficulty : data complexity prevents deep analysis and data‑driven decision making.

1.2 Purpose of the Tagging Platform

Structure non‑standard attribute data : transform scattered, unstructured information into structured tags for standardized management.

Improve product management and filtering efficiency : enable fast tag‑based selection and management.

Enhance user experience : provide precise tag‑based search and recommendation.

Enable data‑driven operations : leverage tag data for deep analysis and decision support.

2. System Overview

The platform is divided into three layers: Application, Service, and Data.

Application Layer: entry point offering UI (admin console, tag components) and RPC interfaces for interaction.

Service Layer: core business processing, handling tag matching, lifecycle management, offline data, product management, and data integration.

Data Layer: provides diversified storage – MySQL, Elasticsearch, local cache, and Redis – to meet different data access needs.

3. Ensuring Tag Real‑Time

3.1 Background

Real‑time tag updates are critical for user experience and operational efficiency; the design must guarantee immediacy.

3.2 Core Design

Traffic Separation : distinguish high‑priority incremental tagging from non‑real‑time batch tagging to avoid interference. Accelerate real‑time tagging response : incremental tagging reacts to events via message queues, reducing latency. Reduce batch impact on real‑time : isolating batch tasks prevents performance contention. Resource isolation for stability : separate resources improve overall system stability.

Event‑Driven : listen to product changes (creation, update, price, attributes) and trigger tagging immediately.

Deduplication MQ : add deduplication queues for ES processing and incremental tag matching to avoid duplicate work and improve accuracy.

4. Ensuring Data Consistency

4.1 Background

Batch (stock) tagging processes massive data; any failure can cause inconsistency, so a comprehensive mechanism is required.

4.2 Mechanism Breakdown

Global Unified Entry : a single entry point ensures every tagging task follows the predefined workflow.

Global Mutex : a global lock guarantees only one stock‑tagging task runs at a time, preventing concurrent conflicts.

Global Exception Capture : captures unexpected errors, records progress, and provides data for recovery.

Exception Task Recovery : before a new task starts, it checks for previous failures and resumes from the last checkpoint.

Asynchronous Data Processing : leverages MQ persistence and reliable delivery to ensure downstream execution and reduce data loss.

These steps—from global mutex to checkpointing, reliable MQ, and exception monitoring—collectively ensure the completeness, accuracy, and reliability of stock‑product tag updates.

5. Eliminating Data Read Bottleneck

5.1 Background

Rule‑based matching requires frequent reads of tag base data; direct MySQL reads under high concurrency become a performance bottleneck, prompting a multi‑level cache design.

5.2 Core Idea

Cache Data Maintenance MySQL remains the source of truth; upper‑level caches reflect its changes. Proactive cleaning of local and Redis caches at the start of stock‑tagging tasks ensures fresh data. Data is loaded on demand from the authoritative source (Redis or MySQL) and then cached.

Cache Data Reading Cache‑first principle: the tagging flow always prefers cached data for performance. Fault‑tolerant fallback: if a cache layer fails, the system gracefully falls back to the next layer or the database.

The multi‑level cache balances performance, consistency, and reliability, supporting an efficient and stable tagging pipeline.

6. Future Vision

The tagging platform will continue to scale, aiming to support tag processing from millions to tens of millions of products and to evolve tag structures (e.g., tree‑shaped tags) for higher matching efficiency.

Product dimension: support tagging at the ten‑million level.

Tag dimension: structural and hierarchical tag handling.

7. Conclusion

The successful practice of Zhuanzhuan’s product‑tagging platform demonstrates that structuring non‑standard data is crucial for fine‑grained operations in a second‑hand marketplace. By combining layered architecture, event‑driven design, message queues, multi‑level caching, and robust consistency mechanisms, the platform resolves operational pain points and provides strong technical support.

About the author Cheng Jun – Zhuanzhuan B2C Java Development Engineer