Design and Evolution of JD's Billion‑Scale Billing System
This article details the architectural design, evolutionary stages, and core components of JD's massive billing system, covering its compliance, componentization, B‑PaaS strategy, unified business identity, dynamic calculation models, and extensible domain‑driven framework for large‑scale financial transaction processing.
Overview: JD's billion‑scale billing system is built to support diversified retail services, integrating information, fund, and invoice flows into a unified financial value‑added service for enterprises, governments, partners, and cloud solutions.
System Positioning: Serves finance, accounting, distributors, and business units as an independent product, offering a comprehensive solution for transaction billing.
Billing System Evolution: The system has progressed through three major phases—Compliance, Componentization, and B‑PaaS—each addressing regulatory demands, scalability, and modular service delivery.
Compliance Phase: Initiated to meet tightening internet transaction regulations and handle massive billing volumes, focusing on financial‑fund flow compliance and asynchronous message‑driven task processing.
Componentization Phase: Since 2018, the system abstracted common service logic into platform capabilities, enabling overseas site empowerment through reusable components such as identity, order, calculation, and rate modules.
B‑PaaS Phase: Addresses challenges of fragmented component design, lack of unified guidelines, and low front‑back collaboration efficiency by establishing unified design principles, domain‑level productization, and self‑service extension packages.
Platform + Business Extension Packages: The architecture separates a common platform (providing core billing models, processes, and rule calculations) from business‑specific extension packages that encapsulate custom logic.
Unified Business Identity: Defines a standardized identity for each billing scenario, encompassing dimensions like order, merchant, product, region, and various transaction stages, encoded into a fixed‑length ID similar to an identity card.
Identity Implementation: Uses a dynamic scripting engine to generate identity IDs based on contextual data, with steps including data bundling, script loading, rule execution, and ID matching.
Business Extension Package Design: Aligns with hexagonal architecture, dividing the system into merchant account, calculation, and settlement domains, each exposing extension points via a matrix‑based plugin mechanism.
Domain Model & Extension Points: A single business requirement may trigger multiple extension points across domains, illustrated with ICF and commission examples.
Dynamic Calculation Model: Configured per business identity, it includes fee items, calculation scripts, snapshot data, and publishing templates, all driven by standardized dictionaries and scripts.
Core Calculation Process: Involves receiving external MQ messages, generating transaction tasks, identifying business identity, normalizing external data, fetching calculation rules, executing scripts to produce billing details, and synchronizing results with the financial settlement platform.
Conclusion: The billing system will continue evolving through domain planning, extension point reuse, and collaborative development to sustain business growth.
JD Retail Technology
Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.