Design and Implementation of a Real‑Time Final Price (到手价) Module for E‑commerce

1 Background Introduction

1.1 Problem

Search result landing pages filter and sort by price inaccurately.

Products shown after price filtering do not match actual inventory, causing missing items and a poor shopping experience.

1.2 Position of the Final‑Price Module in the Promotion Architecture

The final price (到手价) of a product involves coordination among red‑packet, activity, and other modules. By aggregating product price, red‑packet discounts, and promotional reductions, the system computes the final price presented to the customer.

2 Design Goals

Experience : Users see the latest final price promptly, improving shopping experience.

Real‑time : Reduce update latency from half an hour to within three minutes.

3 Core Technical Solution

3.1 Influencing Factors

Main factors affecting the final price:

Product creation or price change.

Red‑packet addition, deletion, or expiration.

Activity or club membership addition or removal.

3.2 Calculation Formula

The detailed discount items on the product detail page can be summarized as:

Final Price = Original Price - Promotional Discount - Maximum Red‑packet Discount

4 Implementation Process and Effects

As business needs evolve, the system continuously adds new features or improves existing ones. Version evolution (v1.0 → v2.0 → v3.0) introduces new modules and optimizations to meet performance and user‑experience requirements.

4.1 v1.0 Process

v1.0 consists of two steps:

Scheduled task pulls the full list of products for a specific business line and pushes them to all downstream systems.

The promotion system provides a lookup API that, given a product ID, returns the final price.

4.2 v1.0 Tasks and Interfaces

Long execution time and occasional failures; users typically wait ~30 minutes to see the latest price.

Additional single‑product and batch‑product APIs increase query pressure; QPS grows with the number of downstream partners.

4.3 v2.0 Design

To address the half‑hour latency of v1.0, v2.0 introduces real‑time processing for events that can immediately provide the product’s infoId, enabling instant final‑price calculation and push.

Real‑time handling of product publish/price change, activity/club join or removal.

These events generate MQ messages containing the product infoId, which trigger immediate price computation.

3‑minute batch task calculates the full‑list final price for a specific business line.

Red‑packet updates (add/update/delete/expire) affect large product sets; therefore a separate handling path is required.

Message format for pushing final price:

[
  {
    "infoId": "16606xxxxxxx174465",
    "ptType": "10",
    "realPrice": "638000"
  }
]

Redis stores the full product list; based on product up/down events, items are added to or removed from queues. The full list is sharded into 10,000 queues, each holding a subset of products:

queue1=[infoId...]

queue2=[infoId...]

... 

queue9999=[infoId...]

Multiple threads compute final price for their own queue; monitoring shows all threads finish within ~120 seconds.

Key considerations:

Avoid unnecessary computation by maintaining a separate red‑packet change queue.

Handle concurrency: if a product changes while a batch task runs, place it into a compensation queue for delayed processing.

4.4 v3.0 Design

As product volume grows, computation time scales linearly.

Solution: introduce sharding. v2.0 uses multi‑threaded JVM execution; v3.0 distributes the large task across multiple shards, each executing its own queue, improving efficiency and reliability. Adding more shards as data grows reduces latency.

5 Summary

System Scalability : The architecture must support growth in data volume and allow upgrades.

System Stability : Continuous business iteration and architectural upgrades must keep the system stable.

Comprehensive Monitoring & Alerts : Real‑time monitoring and alerting enable quick issue detection and resolution.

Evolution Principles : Avoid over‑design early on; adopt different architectures at different stages and iterate continuously.

About the Author

Xiong Xianze, R&D Engineer in ZhaiZhai Transaction Marketing Technology Department. Code creates the future, embraces challenges, and continuously learns and grows.