Evolution of JD.com Order Center Elasticsearch Cluster Architecture

JD.com’s order center initially stored order data in MySQL, but the high query volume required offloading to Elasticsearch. The early ES deployment used default settings on mixed cloud resources, leading to instability and single‑point failures.

To improve stability, the cluster was moved to dedicated physical machines, and later each ES node was placed on its own server to maximize resource usage. Replica count was increased from one to two, and a load‑balancing VIP was introduced, boosting throughput.

A primary‑secondary (master‑backup) architecture was added, with business‑level dual writes ensuring data consistency. The backup cluster stores recent hot data (≈10% of total) while the primary holds the full dataset, allowing both clusters to serve queries and fail over seamlessly.

During a major upgrade from ES 1.7 to 6.x, the backup cluster temporarily acted as the primary to avoid downtime. The upgrade required reindexing because direct migration across multiple versions is unsupported.

Key operational lessons include avoiding deep pagination (which forces each shard to process large result sets), replacing FieldData with Doc Values to reduce heap usage, and configuring refresh intervals to balance near‑real‑time search with query latency.

Data synchronization from MySQL to ES is performed via direct ES API calls during business operations, with a compensation mechanism that records failed writes and retries them asynchronously to maintain eventual consistency.

The architecture continuously evolves with business growth, aiming for higher throughput, better performance, and greater stability.