Overview of Vivo Mall Promotion System Architecture and Technical Challenges

Introduction

As the business channels of the Vivo Mall expand and promotional play‑ways increase, the original v2.0 architecture can no longer satisfy the growing number of activities. An independent promotion system is required to decouple from the core mall and provide pure marketing capability.

We will introduce the problems encountered during the construction of the promotion system and share architectural design experiences.

System Framework – Business Overview

The previous v2.0 promotion model suffered from three main issues:

Promotion model was not abstract enough, leading to chaotic maintenance and no independent activity inventory.

Confusing activity mutual‑exclusion management and lack of unified pricing capability.

Performance could not meet large‑scale activity demands, affecting the main site.

To address these pain points, the first phase delivered core capabilities such as unified discount activity management, independent activity inventory, and a flexible pricing engine. The unified pricing flow is shown in the following diagram:

After the first phase, many new discount play‑ways emerged, bringing new operational challenges such as difficulty in pre‑checking activity effects and increasing configuration complexity.

Promotion and Coupons

Coupons are a subset of promotions. They remain a separate, mature middle‑platform system and have special business logic (issuance, claiming). Therefore, they are not merged into the promotion system, but the pricing engine still depends on coupon discounts.

Business Architecture & Process

The overall promotion system architecture is illustrated below:

The relationship between the mall shopping flow and the promotion system is shown here:

Technical Challenges

As a middle‑platform capability, the promotion system faces challenges in scalability, high concurrency, and overall stability.

Scalability

Definition of a unified discount model for all activities.

Establishment of a unified pricing engine.

Further detailed designs will be covered in subsequent articles.

High Concurrency / High Performance

Cache : Extensive use of Redis and local caches, with careful handling of data consistency.

Batching : Convert many small I/O operations (DB, Redis, remote calls) into batch requests to reduce interaction overhead.

Simplification / Asynchrony : Move non‑core tasks to asynchronous processing (e.g., cache updates after activity edits).

Hot‑Cold Separation : Separate frequently accessed (hot) data from cold data, applying appropriate caching strategies.

System Stability

Rate Limiting & Degradation : Use company‑wide rate‑limiting components to protect core services under load.

Idempotency : Ensure all interfaces are idempotent to avoid duplicate processing.

Circuit Breaker : Apply Hystrix to guard external calls.

Monitoring & Alerting : Configure log‑based alerts, trace analysis, and middleware monitoring to detect anomalies quickly.

Pitfalls

4.1 Redis SCAN Command Usage

Using SCAN for fuzzy key deletion can cause high Redis load and response spikes in large‑scale scenarios. The solution is to redesign keys and replace SCAN with precise key matching.

4.2 Hot Key Problem

During large promotions, SKU‑level Redis keys become hotspots, causing node load imbalance. Two common solutions are key hashing and multi‑level caching. The team adopted a multi‑level cache with hotspot detection, local caching, cluster broadcasting, and pre‑warming to mitigate the issue.

Conclusion

This article provides an overview of the Vivo Mall promotion system, summarizing its business capability evolution, architectural design, and the technical problems and solutions encountered. Future articles will dive into core modules such as discount activity management, pricing engine, price monitoring, and the “time‑travel” feature.