How Vivo Built a Scalable, Decoupled Promotion System for Its E‑Commerce Platform

Introduction

As the Vivo mall added more sales channels and promotional tactics, the legacy v2.0 architecture could not keep up with the increasing number of activities. An independent promotion system was built to decouple marketing capabilities from the core mall and provide a pure promotion service.

System Framework

Business Issues in v2.0

Promotion model was not abstracted, leading to chaotic maintenance and no independent inventory control.

Inconsistent coexistence and mutual‑exclusion management of activities, lacking a unified pricing capability.

Pricing logic was duplicated across product detail, cart and order modules, causing development overhead and performance bottlenecks.

Phase‑1 Core Capabilities

Promotion Activity Management – unified model and UI for creating, editing, querying and reporting activities, with independent inventory control.

Promotion Pricing Engine – layered, abstract pricing engine that defines discount‑stacking rules and a unified calculation flow, ensuring consistent price computation across all mall links.

Promotion and Coupons

Coupons are a subset of promotions but remain a mature middle‑platform service from the v2.0 era. They were not merged into the new promotion system to avoid redesign cost, although the pricing engine still depends on coupon discount data.

Architecture Overview

The promotion system is a decoupled middle‑platform that interacts with the mall’s shopping flow. The overall architecture and the updated shopping process are illustrated below.

Technical Challenges

Extensibility

Unified discount model – all promotion types are abstracted into a single configurable model.

Pricing engine – a consistent calculation framework that isolates pricing logic from business modules.

High Concurrency / High Performance

Caching – extensive use of Redis and local caches, with strategies to keep data consistent.

Batching – convert many small I/O operations (DB, Redis, remote calls) into batch requests to reduce latency.

Asynchronous processing – move non‑core tasks (e.g., cache refresh after editing, message sync) to background workers.

Hot‑cold separation – store frequently accessed SKU‑level reservation records in hot caches while archiving cold data.

System Stability

Rate limiting & degradation – internal flow‑control components protect core services under load.

Idempotency – all APIs are designed to be idempotent to avoid duplicate processing on retries.

Circuit breaking – Hystrix isolates failures of downstream services.

Monitoring & alerting – log‑based error alerts, tracing analysis and middleware health checks enable rapid incident detection.

Pitfalls Encountered

Misuse of Redis SCAN

Fuzzy key deletion using SCAN reduced blocking compared with KEYS, but in large‑scale scenarios it still caused load spikes and latency spikes.

Solution: redesign Redis key schema to reduce unnecessary entries and replace SCAN with precise key matching for deletions.

Hotspot Key Issues

SKU‑level caches can become hotspot keys during product launches or large sales events, leading to uneven node load and instability.

Two common mitigations:

Hashing – distribute keys evenly across Redis cluster nodes.

Multi‑level caching – add a local cache layer for hotspot keys to offload Redis.

Vivo adopted the multi‑level approach, extending an open‑source hotspot cache framework with detection, local caching, cluster broadcasting and pre‑warming capabilities.

Conclusion

The Vivo promotion system evolved from a tightly coupled module in v2.0 to an independent middle‑platform that provides unified activity management, a flexible pricing engine, and robust high‑performance and stability mechanisms. The article documents the architectural decisions, technical challenges, and concrete solutions such as unified discount modeling, batch I/O, hot‑cold data separation, rate limiting, idempotent APIs, circuit breaking, and hotspot key mitigation.