Evolution and Architecture of JD.com CMS: From Virtual Classification to CMS‑Portal System

JD.com’s Content Management System (CMS) was introduced in 2014 to enable rapid development and unified publishing of vertical channel pages, reducing repetitive work by managing data and templates centrally.

The CMS has evolved through three stages:

CMS 1.0 – Virtual Classification System: A standalone data maintenance platform providing basic promotional data, requiring separate development and deployment for each channel.

CMS 2.0 – Integrated CMS: Unified data structures, migrated to Redis, achieved >3000 TPS per instance, introduced single‑point publishing, modular design, and dynamic data types.

CMS 3.0 – CMS‑Portal System: Emphasizes speed, front‑back separation, mobile support, high performance, and comprehensive management.

The current architecture consists of several components:

CMS system for data management and page generation.

Data Worker Center for third‑party validation and page publishing.

Single‑point servers storing generated pages per data center.

Page Update Workers synchronizing content to a static application server cluster.

Static application server cluster for fallback when single‑point servers fail.

Asynchronous personalization services for dynamic data such as price, inventory, and recommendations.

NGINX access layer handling routing and graceful degradation.

Key design ideas include introducing dynamic data types that can be extended without schema changes, a component‑based template system (modules, components, floors) enabling true front‑end rendering, and a closed‑loop data flow ensuring independence from external services.

Dynamic data types are defined via JSON field definitions, allowing flexible promotion content (text links, small images, product pools). Components combine modules with HTML snippets to render pages entirely on the front end.

Dynamic services built with Lua and Redis support up to 20,000+ QPS on a single 16‑core machine, providing APIs for address, category, and recommendation data.

Disaster recovery is handled at both application and server levels: strict data validation during preview, version rollback for static assets, asynchronous service monitoring, and multi‑data‑center deployment with automatic traffic shifting.

Intelligent product selection leverages big‑data pipelines to deliver personalized recommendations, improving conversion rates for JD Supermarket, industry channels, and major promotional events.

Operational pitfalls encountered include uncontrolled rsync processes during file synchronization, which were mitigated by implementing a lock file, and the necessity of a complete data closed‑loop to avoid external API instability.

In summary, JD.com’s CMS now supports thousands of PC and mobile pages, with ongoing work focusing on visual editing, analytics, keyword management, and product off‑shelf alerts.