Design and Evolution of the Vivo Mall Inventory System Architecture

The article, authored by the Vivo official mall development team, introduces the development history, architectural design ideas, and practical implementations of the Vivo Mall inventory system.

Business background: The inventory system is the core of e‑commerce product management. The original monolithic inventory was coupled with the product system; to handle increasing business complexity, the system was split into services and added functionalities such as physical stock, flash‑sale stock, logistics timing, shipping restrictions, and warehouse management.

System architecture design: The overall inventory architecture is divided into three layers—warehouse layer (physical warehouses, third‑party warehouses, WMS/ERP), scheduling layer (stock scheduling and order dispatch), and sales layer (official mall, stores, third‑party channels). The official mall inventory resides in the sales layer and interacts with the scheduling layer.

Architecture evolution: Early versions suffered from redundant stock data, limited stock flow, and poor real‑time performance. In 2021 a new architecture was designed and iteratively refined, resulting in a system that provides two core capabilities—transaction processing and stock management—exposed via APIs for stock queries and deductions, with a management console for warehouse strategies and synchronization.

Business architecture: Four stock types are defined—sellable stock, physical stock, pre‑occupied stock, and activity stock. Warehouse information, split‑warehouse strategies, and warehouse stock are maintained. Stock flow includes forward deduction (order‑time or payment‑time) and reverse rollback, with the chosen approach being order‑time deduction plus timed rollback to balance user experience and abuse prevention.

Technical key points: To prevent duplicate deductions, the system ensures idempotent APIs by adding a unique order sequence number and checking deduction logs. High‑concurrency deduction solutions include direct database updates with optimistic locking, distributed locks, and a Redis + Lua script approach for flash‑sale scenarios. Cache‑to‑DB synchronization is handled via asynchronous tasks, and hotspot problems are mitigated by sharding stock rows and dispersing Redis keys.

Stock synchronization: Physical stock is synchronized from warehouse systems via scheduled full‑sync or on‑demand updates. Historical stock data from the product system is kept consistent using a CDC pipeline (Luban platform) that captures binlog changes, filters them, publishes MQ messages, and updates the product system.

Sample SQL for direct database deduction (idempotent approach): sql: update store set store = store - #{deductStore} where (store-#{deductStore}) >= 0

Summary and outlook: The inventory system has been successfully split into services, expanded with multiple stock types, and equipped with solutions for deduplication, high‑concurrency, hotspot mitigation, and synchronization. Future work aims to provide an integrated inventory management platform for Vivo’s new retail initiatives.