Scaling JD.com's POP Platform: From V1.0 Monolith to V3.0 Microservices

V1.0 Version

In 2010 JD.com’s Open Platform (POP) was launched with a minimal architecture to support merchant onboarding, storefront sales, product and order management. The system was built in less than a month by a team of fewer than ten people. It consisted of a business layer (operational backend for JD staff and merchant backend for sellers) and a data layer. The business layer used Apache + Tomcat, while the data layer relied on Oracle on a small server and FastDFS for small‑file storage.

V2.0 Version

One year later rapid growth forced a redesign. Problems of the V1.0 monolith included tight coupling, database overload, and scattered asynchronous logic. The solution was a micro‑service architecture that split the system into independent subsystems (product, order‑delivery, merchant onboarding, etc.) and replaced Apache with high‑performance Nginx. An asynchronous work‑scheduling system was built using NoSQL and inter‑process communication to manage background tasks more efficiently. The data layer diversified to include Redis, MySQL, MongoDB, MQ, Solr, Hadoop, and introduced caching and Solr for complex queries. An open platform was created with independently deployed RESTful APIs secured by OAuth 2.0, along with rate‑limiting and degradation mechanisms, plus sandbox testing and a developer center.

V3.0 Version

The focus shifted to service‑orientation, standardization, and unification. Core e‑commerce functions were exposed as SOA APIs governed by JD’s custom RPC framework JSF. Oracle was phased out in favor of sharded MySQL databases with extensive partitioning. Internal tools such as a unified configuration center and a unified monitoring platform were introduced to manage feature flags, degradation, rate limiting, and system health metrics.