Integration of JD Service Market and Plugin Market: Architecture, Data and Process Fusion

The article describes the integration project between JD Service Market and JD Plugin Market, two originally independent closed‑loop business systems, each with its own merchant flow, service publishing, order payment, and settlement processes, and explains how they were merged into a single platform.

System Overview

The functional analysis of both markets was performed, followed by a detailed architectural decomposition of pages, features, workflows, and data models. The final architecture diagrams (shown below) illustrate the unified system.

Data Fusion

Unified the underlying data models for merchants, services (including versioned modules), subscriptions, orders, settlements, and refunds across both markets.

Process Fusion

Combined order subscription, payment, service publishing review, settlement, invoicing, refund, cancellation, rating, and service search workflows into a single end‑to‑end process.

Feature Migration

Migrated backend management functions (service management, transaction management, settlement management, operations, information, contract management) from the Service Market admin to the unified platform, and similarly consolidated the Plugin Market admin capabilities.

External Service Refactoring

Implemented server startup process redesign and adopted a front‑back separation architecture.

Service Publishing Review Fusion

Original: Two independent publishing paths in Service Market (IFW) and Plugin Market (ISV). Transition: Redirect publishing from IFW to ISV, introducing a dual‑write mechanism that writes to both databases when publishing from the Plugin Market. Final: Only the ISV entry remains; the dual‑write is removed after upstream integration.

Rating Process Fusion

Original: Separate rating databases; Plugin Market rating disabled. Transition: Keep Service Market rating unchanged, redirect Plugin Market rating actions to the Service Market backend, writing via the product middle‑platform. Final: All rating operations go through the product middle‑platform.

Service Search Fusion

Original: Two separate scheduled jobs populate Solr caches from each market. Transition: Merge the jobs, unify product data, and query a new product store; usage counts are fetched from the subscription fulfillment middle‑platform. Final: Solr is replaced by Elasticsearch.

Transaction Fusion

Order & Subscription Fusion : Adopted a database dual‑write (BinLake) approach to keep both original databases in sync while gradually shifting traffic to a new unified database. After cut‑over, the dual‑write is removed and all operations go through the subscription fulfillment middle‑platform.

Settlement Fusion : Used the same dual‑write mechanism to synchronize settlement records; after migration, the Plugin Market is decommissioned and settlements are handled by the payment center via the new settlement database.

Refund Fusion : Consolidated refund handling into the subscription fulfillment middle‑platform, delegating reverse settlement to the payment center and generating refund records centrally.

Cancellation Fusion : Unified cancellation flow by first updating order status in the Service Market, then invoking the payment center; Plugin Market cancellation remains unchanged until the market is retired.

Invoice Fusion : Unified invoice creation and query through the subscription fulfillment middle‑platform and payment center, with data finally stored in the new unified database.

External Service Refactoring

Created a dedicated Service Engine to handle business rules, scenarios, and gameplay acceleration, decoupling these concerns from the product middle‑platform.

Front‑Back Separation Architecture

Implemented a front‑back separation design using Nginx for request routing (JSONP was discarded for security reasons). HTML resources are proxied to a front‑end Nginx, while API calls go directly to back‑end services, keeping the front‑end domain hidden from external exposure.

Conclusion

The Service Market system emphasizes data stability, high availability, and consistency, especially for financial flows such as service fees, commissions, and payments. Unlike previous gateway systems focused on sheer traffic volume, this platform requires robust service governance and architectural governance to ensure reliable e‑commerce operations.