Design and Practice of the Freight Business Check System (BCS)

Preface

During iterative development, bugs inevitably appear; while many are caught before release, some slip through and cause significant financial loss. The freight team seeks ways to detect and resolve issues promptly, both before and after they surface.

Freight Business Overview

The freight system consists of B‑side (merchant and platform operations) and C‑side (real‑time freight calculation) services. It supports internal JD.com operations as well as co‑built services such as the "Hourly Purchase" feature, where merchants configure freight data that is synchronized to the JD main site.

BCS Design and Practice

The Business Check System (BCS) defines several validation modes, each suited to specific scenarios.

Consistency Check for Heterogeneous Data

Applicable scenarios include multiple vertical entry points with high miss rates and back‑track computation contexts.

High miss rate due to many entry points (open platform, merchant center, etc.).

Complex back‑track logic requiring context verification.

Business Logic Correctness Check

Applicable scenarios include operational mistakes and business or technical loopholes.

Operational mis‑operations.

Business or technical vulnerabilities.

Consistency Check Implementation

The core idea is reverse (final‑state) consistency verification, comparing stored data in the freight system with data on the JD main site, avoiding the need to validate every upstream process.

Two implementation schemes were evaluated:

Implementation

Pros and Cons

Forward delayed verification + reverse notification

Pros:

Fast detection of mismatches after bidirectional sync.

Cons:

Tight coupling with JD main‑site changes; high development effort.

Periodic polling data comparison

Pros:

Independent of business changes; focuses on final results.

Cons:

Full‑volume comparison is time‑consuming and introduces latency.

Considering trade‑offs, the periodic polling approach was chosen because it can operate independently of business logic and incurs no integration cost.

The task flow includes a task publisher that periodically fetches full‑volume store data into a task pool, and a task executor that pulls freight data from both systems and applies configured validation rules.

Business Logic Correctness Check Implementation

Data is collected via an AOP‑based annotation mechanism, asynchronously reported via HTTP, and aggregated for rule‑based validation. The collected data supports real‑time alerts, manual troubleshooting, and statistical analysis of freight details.

The system also provides a visual query interface to locate inconsistencies and manually correct data when synchronization fails.

Summary and Outlook

The freight BCS system, derived from existing freight business, has already resolved many production issues. Future work includes more flexible rule configuration, precise alerting, and automated correction of problematic data.