JD Daojia Backend Architecture Overview: Microservices, Gateway, Order System, and High Availability

At the Global Architect Summit held on December 8 in Beijing, Zhou Huawei from Dada‑JD Daojia shared the overall architecture evolution and key technical points of JD Daojia.

The presentation used the order transaction flow as a thread through the entire backend system, starting with an overall architecture deployment diagram, then discussing microservice migration issues, the gateway system architecture, the order system design and common problems, and finally high‑availability considerations.

Physical Deployment Architecture

Requests enter through a front‑end domain, reach an HAProxy cluster, and are routed to two A/B clusters. The application service layer calls business SDKs (which aggregate RPC services). Initially a separate layer was used, later replaced by a gateway.

Microservice Migration

Figure 1: Reasons for microservice adoption.

Microservices bring many benefits but also drawbacks such as increased system complexity, harder monitoring, and distributed transaction challenges.

NOTE: Microservice adoption should be measured.

Gateway

Figure 3: Gateway architecture.

The gateway handles access control, unified security, and traffic analysis. Configuration data is stored in Redis and a database, refreshed via Zookeeper, and cached in the JVM of each gateway instance.

NOTE: Traffic distribution, security control, and data analysis.

LBS Caching

Figure 4: Location‑based caching.

To reduce latency for nearby store queries, the system uses Mercator projection to bucket coordinates into grids, using the grid key for caching, cutting response time from 500 ms to about 10 ms.

Order Main Architecture

Figure 5: Order system architecture.

The order flow separates TOC order creation from TOB production, uses a pipeline to protect downstream systems, and handles peak‑shaving. Key concerns include service dependency management, data consistency, and idempotency.

Figure 6: Common issues.

Idempotency : Redis distributed locks, INCR, SETNX are used to ensure idempotent resource consumption.

Asynchrony & Caching : Asynchronous processing via threads, MQ, etc., and caching (local, remote) are employed to handle high concurrency without blocking the main flow.

Data Consistency : Strategies include database transactions, worker queues, MQ compensation, and RPC retry mechanisms to keep internal caches, databases, Elasticsearch, and external systems in sync.

Over‑Design : Some SDK layers were removed to simplify the web layer, reducing maintenance cost.

Figure 7: Storage combination example (database, JVM, Redis, Zookeeper, Elasticsearch, etc.).

Choosing the optimal storage combination based on business scenarios is crucial for efficiency and error reduction.

NOTE: Summarizing business scenarios to find the best combination is key.

High Availability

Figure 8: Monitoring example.

Monitoring should be comprehensive and visualized; many systems have extensive metrics but lack usable dashboards.

Figure 9: Additional high‑availability diagram.

Gray Release : Large or critical changes require A/B testing and gray deployment, with careful parameter selection to minimize impact and avoid dirty data or cascading failures.

Rate Limiting & Degradation : Rate limiting (token bucket, leaky bucket) protects the system during spikes; degradation must consider business impact, e.g., handling shipping fee fallback appropriately.

Stress Testing : Includes limit testing to find concurrency boundaries and daily flow testing to verify logical robustness; realistic traffic simulation is essential.

Recruitment notice: Dada‑JD Daojia's R&D centers in Beijing, Shanghai, and Chengdu are hiring engineers. Apply via [email protected] (Beijing/Chengdu) or [email protected] (Shanghai).