Design and Key Considerations of JD Digits' Accounting Settlement System

System Responsibilities Overview – The accounting settlement system is a core component of JD Digits' payment platform, responsible for recording customer prepaid fund inflows and outflows, preventing advance payments or misuse of funds, and ensuring the safety of customer prepaid capital.

It consists of two main parts: accounting (账务) and settlement (清结算). The accounting part provides real‑time posting and end‑of‑day batch processing to generate accounting vouchers, ledgers, and financial statements. The settlement part handles clearing, settlement, and reconciliation to achieve two‑way settlement with merchants.

Key Points in System Construction – The design must handle real‑time high‑volume transactions, hotspot accounts for key merchants, and diverse settlement rules. Challenges include uncontrolled transaction peaks, complex database table splitting for hotspot accounts, and varied settlement billing models.

System Function Architecture – The workflow starts with payment system notifications to both accounting and settlement modules. Accounting ensures a one‑to‑one mapping of transaction funds, while settlement processes clearing and settlement, allowing independent failure isolation and weak verification between modules.

Pre‑processing Interfaces – External systems interact through three services: traffic control (to limit request bursts and hotspot account pressure), validation center (integrity, idempotency, account status checks), and decision center (matching transaction, accounting, and settlement rules, and handling circuit‑breaker fallback).

Hotspot Account Handling – Hotspot accounts experience extremely high request frequencies. Strategies include: (1) driver‑level row‑lock aggregation, (2) horizontal database sharding to split hotspot accounts across tables, and (3) application‑level distributed cache to freeze funds and perform real‑time deductions, with periodic compensation to synchronize cache and database.

The implemented solution uses a distributed cache with three modules: real‑time balance processing, cache processing, and timed compensation to ensure consistency and performance.

Database Sharding – Due to massive data volume and uneven distribution, tables are split by customer attributes, date, merchant type, and order ID. KA merchants (high volume) use merchant+date+order sharding; micro‑merchants use merchant‑level sharding; channel data uses daily sharding with hash‑based sub‑tables.

Diverse Settlement Rules – A standard algorithm instruction set supports arithmetic, comparisons, and assignments. Multiple instructions are assembled into a strategy graph, executed sequentially with conditional jumps, enabling flexible billing and settlement logic for varied merchant scenarios.

Overall, the article presents the architectural design, critical challenges, and implementation details of a high‑throughput, secure accounting settlement system for a large‑scale payment platform.