Evolution of JD.com Order Center Elasticsearch Cluster Architecture

In JD.com’s order center, the sheer volume of order queries made MySQL insufficient, prompting the adoption of Elasticsearch to handle the primary search load.

1. Initial Stage – The cluster started with default settings on elastic cloud, with mixed deployments and single‑point failure risks.

2. Cluster Isolation Stage – To avoid resource contention, high‑load nodes were moved off shared elastic cloud to dedicated high‑spec physical machines, improving stability.

3. Node Replica Tuning Stage – Each Elasticsearch node was placed on its own physical machine to maximize resource usage, and replica count was increased from 1 to 2 to boost throughput.

4. Master‑Slave Adjustment Stage – A standby cluster was introduced for failover; data is written to both clusters (primary sync, secondary async) and older orders are archived to keep data volume balanced.

5. Current Real‑Time Dual‑Cluster Stage – The primary cluster was upgraded from ES 1.7 to 6.x, with the standby cluster temporarily serving traffic during upgrade, resulting in a hot‑data primary and a cold‑data secondary architecture.

Data Synchronization – Two approaches were considered: MySQL binlog listening and direct ES API writes. The latter was chosen for simplicity and low latency, with a compensation worker handling occasional write failures.

Encountered Pitfalls

High‑real‑time queries still use MySQL due to ES refresh latency.

Deep pagination (large from ) causes excessive resource consumption; it should be avoided.

FieldData consumes JVM heap and can cause OOM; switching to Doc Values (column‑store) mitigates this.

Overall, rapid business growth drove continuous architectural refinements, and while the current setup meets today’s needs, further scaling and optimization will be pursued.