Evolution and Optimization of JD B2B Platform Architecture

JD's B2B platform, built around distribution and consignment business, connects merchants of all sizes to provide a one‑stop procurement and sales solution.

The platform serves two main user groups: large B‑users (e.g., telecom operators) and small B‑users (e.g., local supermarkets).

To support these users, JD maintains core systems such as order, product, pricing, user, permission, and audit services.

Business Development Phases

Phase 1 (2014) : JD entered the B2B market by partnering with China Unicom, marking the start of the large‑B business.

Phase 2 (2015‑2016) : Rural e‑commerce grew, prompting JD to launch the New Channel Division and target the small‑B market.

Phase 3 (2017‑present) : Rapid growth in traffic and data volume required a major architectural overhaul.

B2B Technical Architecture Evolution

Architecture 1.0 consisted of three layers:

Business layer – all B‑platform business lines.

Service layer – SOA services for order, pricing, product, user, etc.

Storage layer – MySQL database.

Problems identified in this version:

Long development cycles.

High coupling between services; a failure in one service could affect others.

Shared databases causing cross‑service impact.

Service‑level Improvements :

Step 1 – Split each business line’s services into smaller, independent services.

Step 2 – Consolidate duplicated services into common reusable services.

Testing Scheme (mixed manual and automated): configuration, data collection, request dispatch, data comparison, and verification.

System Coupling Improvement : Introduce JMQ messaging middleware; use optimistic locking for unordered messages.

Database Improvements

Step 1 – Isolate each business system’s data into dedicated databases (order DB, product DB, etc.).

Step 2 – Apply sharding (hash‑based) for large tables using JProxy for horizontal scaling.

Additional considerations include various sharding algorithms, hotspot handling, eventual consistency via asynchronous messaging, and distributed queries.

Distributed Search

Adopt Elasticsearch for full‑text and distributed queries; backup clusters are used for high availability.

Architecture 2.0

Based on 1.0, three main changes were made:

Extract common services from the service layer.

Introduce a foundational tooling layer.

Implement database sharding and partitioning.

New challenges emerged: bloated platform services and duplicated development for personalized requirements.

Architecture 3.0

Further refinements include deeper service extraction, separation of business logic from SOA, and the introduction of configurable components and a configuration center to enable plug‑in services.

Component‑driven design allows external services to be assembled like a factory, improving reusability and flexibility.

Conclusion

After three major iterations, JD's B2B platform has evolved from a tightly coupled monolith to a modular, service‑oriented architecture (3.0) that emphasizes reusable services, database isolation, messaging middleware, and configurable components, providing a scalable foundation for both large and small B‑users.