Evolution and Architecture of JD.com Self‑Operated Rebate Platform

Since its pilot launch in 2014, JD.com’s self‑operated rebate system has served multiple business groups, providing rule management, data aggregation, rebate calculation, settlement, risk monitoring, and analytics across a massive volume of order and policy data.

The original system used a "chimney" monolithic architecture that suffered from weak extensibility, poor stability, lengthy calculation workflows, and high maintenance costs, as illustrated by tangled database table dependencies and complex SQL joins.

To address these issues, JD.com built a new platform (the "Jinfan" platform) starting in 2020, adopting a six‑layer architecture: source tables, extraction layer (offline SparkSQL and real‑time BinLog sync), storage layer (JED relational DB, Elasticsearch, Hive, HBase), computation layer (batch Spark jobs replacing MapReduce), service layer (rule integration and query services), and application layer (dashboards and reports).

Key architectural improvements include database read‑write separation, asynchronous processing, caching, multi‑datacenter deployment for high availability, template‑based extensibility, dynamic field configuration for rebate rules, and a Spark‑based rebate calculation engine that reduces ETL and computation latency.

After deployment, the new platform supported five complex business scenarios within three months, cutting development effort and delivery time by about 50%, and demonstrated significant performance gains in query latency and throughput.

Future work focuses on adding real‑time streaming capabilities, enhancing full‑link data quality monitoring, and further optimizing rebate calculation performance to meet growing business demands.