Inside JD Daojia’s After‑Sale System: Distributed Locks, Data Sync, and Refund Strategies

Introduction

Reading this article gives a comprehensive view of the capabilities required by an after‑sale system, its position within the upstream‑downstream ecosystem, the basic system architecture, and solutions to common business‑scenario problems.

Core Value

The JD Daojia after‑sale system operates as a reverse‑flow service tightly coupled with the delivery domain, covering four major scenarios: refund, return, exchange, and repair, while also supporting appeal and arbitration for users and merchants. It supplies reverse‑flow monetary data to the billing and settlement system.

System Architecture

The platform follows a classic three‑layer architecture:

Application layer: three entry points for different identities (user, merchant, operations).

Service layer: provides business and data support.

Data layer: MySQL, Redis, and Elasticsearch.

Additional middleware includes an RPC framework, ZooKeeper configuration center, distributed task workers, and a JMQ messaging system, together with unified monitoring and log collection.

Business Scenarios

After‑Sale Application Flow

After a forward order is fulfilled, users can request after‑sale services for missing, wrong, or defective items. Requests can originate from the user side, merchant side, or customer‑service side. The system uses a Redis distributed lock to ensure that the same order item is not processed multiple times across concurrent entry points.

All entry points share a lock key prefixed with the order number.

The lock includes an expiration time to avoid deadlocks.

If a lock cannot be obtained, the request waits until timeout.

Each lock is identified by a UUID to guarantee token uniqueness.

After acquiring the lock, the system assembles after‑sale order details from order and split data.

Split Data Retrieval

The split system distributes the total order amount to each SKU, using a num_ index to differentiate items. The after‑sale service identifies the correct split record via sku_promotionType (SKU + promotion type) and the num index.

For promotions where the same SKU appears with different prices (e.g., bundle promotions), an additional price dimension sku_promotionType_price is introduced to avoid incorrect refund amounts.

When weight‑based price adjustments are needed (e.g., weight‑difference refunds), a further dimension sku_promotionType_price_weight is added.

Review Process and Performance Optimization

After an after‑sale request is created, it is assigned to either a merchant or a customer‑service reviewer. Growing data volume caused slow SQL queries and frequent database alarms.

Indexes were added on frequently queried fields, resulting in over 20 indexes on the main table.

To further improve query speed, after‑sale data is synchronized to Elasticsearch, leveraging its inverted‑index and analyzer capabilities for fast fuzzy text searches.

Data synchronization strategy:

Introduce a feature toggle to switch between MySQL and Elasticsearch.

Batch‑sync existing records by primary‑key range while the toggle is off.

After toggling on, new after‑sale records are sent to Elasticsearch via asynchronous MQ messages.

Validate total record count to ensure completeness.

Consistency is maintained by publishing an MQ message after each transaction; the consumer fetches the latest MySQL record and overwrites the Elasticsearch document, guaranteeing that the most recent state is reflected regardless of consumption order.

Potential data lag from MQ delay is mitigated by pre‑validation of order status before any operation and by alerting on repeated sync failures.

Return Logistics – Combined Order Dispatch

When multiple after‑sale return requests belong to the same original order, a combined‑order (合单) logic is applied so that only one logistics dispatch is needed.

A worker scans pending after‑sale orders and triggers a combined task 10 minutes before the earliest scheduled pickup.

The task gathers all return‑eligible after‑sale orders under the same order number and selects the earliest pickup time to create a single shipment.

The shipment creation API is idempotent; repeated calls return the same shipment number.

Result messages from the shipment service update the delivery‑person information.

Failed combined tasks are recorded, retried, and, after exceeding a retry limit, are flagged for manual intervention.

Refund Accuracy and Validation

To prevent duplicate refunds across multiple entry points, a distributed lock is applied at the after‑sale order level.

Line‑item legality checks ensure that the requested refund quantity does not exceed the ordered quantity, and that the total refund does not surpass the remaining account balance.

skuList:[{"skuCount":1,"skuName":"skuA","procotionType":"1"},{"skuCount":1,"skuName":"skuA","promotionType":"1"}]

Finally, the system validates the overall order ledger amount, confirming that the refund amount is less than or equal to the available ledger balance.

Conclusion

The reverse‑flow after‑sale service depends on the forward order and must continuously evolve to support new business scenarios. By modularizing split‑logic, employing distributed locks, synchronizing data to Elasticsearch, and implementing combined‑order logistics, the system achieves both functional correctness and operational efficiency.

Future work includes building a gateway to centralize business logic and adopting a template‑engine configuration to enable smarter, more maintainable after‑sale workflows.