Design and Evolution of JD Daojia Product Governance System

Background

JD Daojia, an instant‑delivery e‑commerce platform, built a product governance system to discover and resolve issues like sensitive words, false advertising, and incorrect information, ensuring product‑to‑real‑item matching and information accuracy.

System Architecture Overview

The platform uses a standardized micro‑service architecture. Key components include:

Message middleware: JD's MQ for decoupling business logic.

Storage: Redis cluster and MySQL cluster.

Worker: Distributed scheduling engine based on TBSchedule for timed tasks.

Service monitoring: Unified monitoring and alerting platform with second‑level, multi‑dimensional monitoring, alerts, and full‑link tracing.

Service invocation: JD's JSF platform for service registration, calls, governance, and automatic timeout blocking.

Log service: Log collection and query.

Early Governance System

The first version focused on CRUD operations and a sensitive‑word management module, providing validation for the main product system. It also offered a reporting feature where operators could upload Excel files, parse them, store results in MySQL, and query/display the data.

However, tight coupling with the product system caused a rapid increase in interface count as new compliance requirements (category, weight, images, etc.) emerged.

Two main problems were identified:

The product system heavily depended on governance validation, and this dependency grew with business expansion.

The product system could only notify merchants of pre‑check results, leaving coverage incomplete.

Consequently, the core governance responsibilities were shifted from the product system to the governance system, guided by two principles:

The governance system must close the entire compliance loop, acting as the sole entry and exit for problem discovery and resolution.

The system must be highly extensible to quickly accommodate new compliance needs.

Business Architecture Upgrade

Abstract Thinking

The fundamental atomic capability of the governance system is to discover compliance issues in products and provide query and assistance for resolution.

Compliance issues are defined as any violation of the platform's product display standards, such as sensitive words or false promotion.

Current compliance categories include:

Compliance Category

Description

Details

Product Gross Weight Issue

Inaccurate gross weight

Weight mismatch, exceeds transport limits, etc.

Incorrect Product Information

Information errors

Sensitive words in name, mismatched category, false advertising, etc.

Merchant Business Scope Issue

Products exceed merchant's allowed scope

Out‑of‑scope items

Image Information Issue

Problems with product images

No main image, default image, black‑background image, etc.

Each compliance issue is treated as a strategy with four core methods: mapping enums, associating fields, custom filtering, and validation logic.

Implementation Patterns

The design follows a variant of the Strategy and Template Method patterns, with factories used during implementation. The architecture diagram (omitted) shows the flow.

Example: for a gross‑weight error, the system maps the issue type, provides a recommended weight, associates relevant fields (weight, name), applies filtering, and runs validation algorithms.

Challenges and Solutions

Business Issue

Operators required that product main images not be default placeholders. The image validation logic resides in a separate image‑validation system.

Solution: Use MQ to let the image‑validation system push results to the governance system, and expose a façade interface so the governance system can aggregate image compliance problems alongside other issues.

Technical Issue

Initial image‑damage detection compared ContentLength with actual byte size, which failed for many merchant image services.

Improved solution: download the image, analyze its content using algorithms tailored to broken‑image characteristics, and extend the approach to handle black‑background and default images.

Governance Reach and Automation

After stabilizing the discovery flow, product demanded automatic handling for certain issues and merchant notification.

Inspired by machine‑learning model types, the system separates discovery and resolution phases, allowing automatic rules (e.g., auto‑deactivate products whose weight exceeds a threshold) while still supporting manual review.

Core workflow:

Product change or external notification triggers compliance checks via MQ.

Validation results are evaluated for manual or automatic handling.

Results are exposed via APIs or MQ to downstream systems.

Full‑View of Governance Business

Since the architecture upgrade, the platform has been running for over nine months, processing more than 4.8 million products, building eight detection capabilities, three handling methods, and two notification channels.

Future Plans

The current governance scope is limited to product‑related workflows; future work aims to extend compliance signals to other systems such as search and recommendation, where compliance scores can influence ranking.

Additional non‑algorithmic issues like high negative review rates or return rates will also be incorporated into the governance framework.

Conclusion

As product quality demands rise, the JD Daojia governance system will continue to collaborate with upstream and downstream services to provide finer‑grained product control, delivering more authentic data and higher‑quality service to users.