Architecture Design and Key Solutions of JD Daojia Transaction System

Background

Although the transaction system may not be the most technically challenging, it has the highest business complexity; an order passes through dozens of systems and hundreds of interfaces, MQs, and resources such as inventory, coupons, and codes, making any single failure critical.

The article highlights typical architectural designs and key problem‑solving approaches used in JD Daojia's transaction system.

Evolution

System Setization

Initially, order, homepage, product page, and cart logic were all in a single large project, which suited early rapid iteration but later caused traffic, complexity, and deployment coordination issues.

Solution : Project setization with careful boundary definition to avoid overly coarse or fine granularity.

Database Sharding

Problem : During peak events like Double‑11, a single DB cluster (one master, multiple slaves) becomes a bottleneck due to limited connections.

Solution : Use hash‑based sharding of order databases by order ID, implemented by extending Spring's AbstractRoutingDataSource and overriding determineCurrentLookupKey . Personal‑center data is also sharded by PIN, and Elasticsearch is used for large‑scale query scenarios.

Frontend‑Backend Order Separation

Problem : ToC (consumer) and ToB (business) have different latency and data consistency requirements; they must not affect each other.

Solution : Separate ToC order system (App/H5) from ToB production system with independent databases; workers based on TBSchedule process orders in parallel with millisecond‑level dispatch.

Parallel Control for Efficiency

Problem : A single "Submit Order" action can trigger over 20 interfaces; serial execution leads to latency beyond the 500 ms target.

Solution : Identify independent services and execute them concurrently in a thread pool (e.g., inventory, product info, promotions). The overall time becomes the longest of the parallel calls, reducing latency by several hundred milliseconds.

Resource consumption and rollback are also parallelized; each resource implements a consume and rollback interface, wrapped as Callable tasks.

Asynchronous Processing

Non‑critical post‑order actions (SMS, address saving, cart cleanup, etc.) are handled asynchronously via thread pools, with compensation workers for failures.

Thread‑pool best practices: avoid unbounded queues (use ArrayBlockingQueue ) and prefer rejection policies over CallerRunsPolicy to prevent main‑thread overload.

Dependency Governance

With hundreds of interfaces, service dependencies can cause cascade failures under high load.

Solution: Implement degradation strategies (default values, circuit‑breaker style fallbacks) and a custom Zookeeper‑based "Luban" system that stores feature‑toggle data per service node; changes propagate to all listeners via local caches (e.g., ConcurrentHashMap ).

Fulfillment Tracking

Developed a UDP reporting system that logs every interface call during order submission, including parameters, exceptions, and IPs, by using a custom Spring AOP annotation that writes to Elasticsearch.

Future plan: route UDP logs to Kafka, process with Storm, and store results in Elasticsearch for real‑time analysis.

Future Outlook

Multi‑Channel Isolation

Separate deployment for WeChat, app, and H5 channels to allow independent releases and gray‑scale testing.

Monitoring Visualization

Plan to create an interactive dependency graph where each node represents a service; colors indicate health status and clicking a node triggers configuration changes for degradation.

Order XMLization

Consider storing each order as a single XML record to reduce table count and simplify scaling; backend workers would later transform XML back to relational tables.

Settlement Page Caching

Cache non‑sensitive settlement data after the user enters the page, allowing fast refreshes and simplifying the final order submission to a single key lookup.

For more technical articles, follow the Dada Technology public account.