How JD’s Open Platform Guarantees Reliable Message Delivery with Dynamic BMQ Design

JD.com’s Open Platform serves as a bridge between merchant data and the JD Home service, enabling two‑way communication through a large set of callable APIs for order creation, status changes, store updates, and promotion approvals.

Message System Core Design

The platform’s Business Message Queue (BMQ) leverages JD’s internal MQ system, which is highly available and reliable. BMQ subscribes to internal business MQ topics, transforms messages into standard or non‑standard formats, and forwards them to merchants.

Because the platform‑provided APIs are stable while merchant‑provided notification APIs can fail (e.g., server crashes, network issues), the design must consider detection, retry frequency, and isolation of failures.

Channel Separation Strategy

Critical (KA) merchants are isolated from regular merchants via dedicated channels. When necessary, a non‑KA merchant can be promoted to a separate channel for processing, converting business‑level isolation into merchant‑level isolation.

However, non‑KA merchants can still affect each other as traffic grows, so further separation by business type is introduced, creating distinct channels for each message category.

Retry and Degradation Channels

Each channel includes a dedicated retry channel to prevent problematic messages from blocking normal flow. If a merchant’s interface hangs, messages are rerouted to the retry channel.

When excessive latency is detected (using Kafka + Flink monitoring), a degradation channel is created. Messages marked for degradation bypass the regular channel and are processed separately, with automatic removal of the degradation flag once the merchant recovers.

Alert Mechanism

Continuous monitoring triggers alerts when a merchant’s messages repeatedly fail beyond a threshold. Alerts are sent via SMS to both the merchant’s responsible person and the platform’s developers.

Tools allow rapid identification of the failing merchant and interface, and provide the ability to temporarily disable problematic messages without stopping retries.

Dynamic Message Publishing

Originally, adding new messages required extensive Java code and a full deployment cycle. To streamline this, the platform introduced a dynamic configuration model where most message handling logic (field mapping, defaults, simple conditions) is defined through a UI.

Dynamic subscription to MQ topics is handled server‑side, eliminating the need for custom listeners. The core code for dynamic loading looks like:

// ips field empty means broadcast to all machines; otherwise target specific IPs
if (StringUtils.isEmpty(dynamicLoadingMessage.getIps()) || dynamicLoadingMessage.getIps().contains(IPUtil.getIp())) {
    // type=0 means load MQ, non‑0 means unload MQ
    if (dynamicLoadingMessage.getType() == 0) {
        openPlatformBMQEngine.getMessageConsumer().unsubscribe(dynamicLoadingMessage.getTopic());
        openPlatformBMQEngine.getMessageConsumer().subscribe(dynamicLoadingMessage.getTopic(), commonBMQListener);
        LOGGER.error("DynamicLoadingListener->onMessage->subscribe->dynamicLoadingMessage:{}", JsonUtils.toJson(dynamicLoadingMessage));
    } else {
        openPlatformBMQEngine.getMessageConsumer().unsubscribe(dynamicLoadingMessage.getTopic());
        LOGGER.error("DynamicLoadingListener->onMessage->unsubscribe->dynamicLoadingMessage:{}", JsonUtils.toJson(dynamicLoadingMessage));
    }
}

After processing, the publishing flow proceeds through a series of steps illustrated in the accompanying diagrams.

Benefits of the Dynamic BMQ Approach

Platform‑wide message handling : Replaces custom integration with rule‑based configuration, providing a unified entry point.

Low‑risk integration : Eliminates manual code changes, reducing deployment risk.

Higher efficiency : Reduces integration time from days to minutes, eventually enabling non‑developers to add new messages.

In summary, the BMQ system’s design—combining stable MQ foundations, isolated channels, retry/degradation paths, real‑time monitoring, and dynamic configuration—delivers a reliable, scalable, and maintainable messaging solution for JD’s Open Platform.