Technical Implementation and Resilience Practices of JD.com PC Homepage

In 2018 JD.com restructured its retail system into a front‑middle‑back architecture, with the middle platform providing core services and the front platform handling user requests. The PC homepage, as the primary entry point, evolved from template rendering to SSI modules and finally to a fully decoupled front‑back architecture using Lua‑based OpenResty.

The system must satisfy three key requirements: page integrity (disaster recovery, fallback, degradation), smooth loading speed (high concurrency, page and API optimization), and robust monitoring & alerting.

Page Integrity ensures that users always see a complete page without gaps or non‑200 responses. Strategies include:

Static HTML generation via a worker that validates templates before pushing to a CDN.

Dual‑layer caching at the API level: a short‑lived acceleration cache and a never‑expiring fallback cache.

CDN API fallback that serves pre‑generated static results when the primary API fails.

NGINX error_page directives to proxy to remote static resources on error conditions.

Floor‑level degradation: hide individual modules when their APIs fail, preserving overall page completeness.

Ultimate fallback (“Never‑Missing Homepage”): periodic snapshots of the homepage are stored and can be served instantly via CDN when all services are down.

NGINX error handling example:

error_page 301 302 404 500 502 504 = @error_callback;</code>
<code>location @error_callback {</code>
<code>    # implement fallback logic</code>
<code>    proxy_pass http://remote_server;</code>
<code>}

Performance Optimizations focus on reducing latency and handling high traffic:

Adoption of OpenResty (NGINX + Lua) for asynchronous, high‑concurrency request processing, with 11 distinct request phases for fine‑grained control.

Redis hot‑key mitigation by caching hot data in ngx.shared.DICT, dramatically cutting response time.

Redis big‑key handling by splitting large values into multiple smaller keys or using pipelining to reduce network overhead.

Distributed task system for personalized recommendation data, pushing user info to background workers that pre‑populate Redis for subsequent floor rendering.

Concurrent upstream RPC calls via ngx.location.capture_multi to avoid serial latency.

Batch log writing in the log_by_lua* phase to minimize disk I/O.

Image delivery optimization through multi‑domain CDN, DNS pre‑fetch, and lazy loading.

Monitoring & Alerting is streamlined by sending log data directly from NGINX workers via non‑blocking ngx.socket.tcp to a distributed task that forwards it to an Elastic cluster, enabling rapid alert propagation to product and operations teams.

In summary, the iterative upgrades of the JD.com PC homepage have resulted in a robust platform built on the Hive (蜂巢) system and the OpenLua framework, combining component‑based design, standardized practices, and high‑performance backend technologies to deliver a fast, reliable user experience.