Design and Architecture of Vivo E‑commerce Inventory System

This article, part of the Vivo Mall series, introduces the evolution, architectural design, and practical solutions of the Vivo Mall inventory system.

1. Business Background

The inventory system is the core of e‑commerce product management. The original system was tightly coupled with the product service, leading to high complexity. To meet growing business needs, the inventory service was split and extended with physical stock, flash‑sale stock, logistics timing, shipping restrictions, and multi‑warehouse management.

2. System Architecture Design

The overall architecture is divided into three layers: Warehouse layer (physical warehouses, WMS, ERP), Scheduling layer (stock dispatch and order fulfillment), and Sales layer (official mall, stores, third‑party channels). The diagram below shows the layered structure:

The article focuses on the inventory architecture within the sales layer and its interaction with the scheduling layer.

2.2 Evolution of the Mall Inventory System

Early versions stored redundant inventory data across multiple services, limiting flexibility. In 2021, a first‑generation design was released and iteratively refined into the current architecture (see diagram).

The system provides two core capabilities: transaction handling and inventory management, exposed via APIs for stock query, deduction, and administrative operations.

3. Business Architecture

3.1 Inventory Types & Warehouse Management

The system defines four inventory types: sellable stock, physical stock, pre‑reserved stock, and activity stock (e.g., flash‑sale). Each type is managed at different granularity (SKU, warehouse, order). A simplified hierarchy diagram is shown below:

Warehouse information, split‑warehouse strategies, and real‑time physical stock are also maintained.

3.2 Inventory Flow

Two main operations: forward stock deduction and reverse stock rollback. The flow diagram is illustrated below:

Deduction can occur at order placement (with a 15‑minute release window) or at payment. Vivo adopts the order‑time deduction plus rollback approach.

3.3 Fine‑Grained Shipping Control

Features include split‑warehouse strategy, regional/time shipping restrictions, and logistics time estimation based on the selected warehouse.

4. Technical Highlights

4.1 Duplicate‑Deduction Prevention

Solutions include disabling the submit button, ensuring idempotent APIs (e.g., using a unique order serial number), and token verification. The implemented approach adds the order serial number to the deduction request and checks for existing logs before processing.

4.2 Over‑Sell Prevention & High‑Concurrency Deduction

4.2.1 Regular Channel Solutions

1) Direct database deduction using optimistic locking: sql: update store set store = store - #{deductStore} where (store-#{deductStore}) >= 0 Advantages: strong consistency, no over‑sell. Drawbacks: row‑level lock bottleneck under high load.

2) Distributed lock to serialize deductions. Advantage: reduces DB pressure. Disadvantage: limited concurrency.

Vivo adopts the direct DB approach for regular traffic, complemented by strict pre‑validation and read‑write separation.

4.2.2 High‑Concurrency (Flash‑Sale) Solutions

Cache‑based deduction using Redis + Lua script for single‑threaded stock updates, followed by asynchronous persistence to the database. Two sync strategies are discussed:

Async bulk update of Redis data to DB (simple but risk of data loss on Redis failure).

Insert a stock‑task record into DB within the same transaction as the Redis deduction, then async sync to the stock table, ensuring eventual consistency.

Vivo uses the second approach for flash‑sale scenarios.

4.2.3 Hotspot Issues

Hotspot problems arise from single‑row DB locks or single‑node Redis contention. Solutions include sharding stock rows (randomly picking one of M rows for deduction) and distributing Redis keys across multiple shards.

4.3 Inventory Synchronization

Two main sync scenarios: physical stock from warehouse systems (full‑batch or per‑SKU) and legacy product‑system stock. Synchronization is achieved via a CDC platform (鲁班) that captures binlog changes, filters them, publishes MQ messages, and updates the product system.

5. Summary and Outlook

The inventory system has been successfully decoupled, expanded beyond simple sellable‑stock deduction, and now supports multiple stock types, high‑concurrency deduction, hotspot mitigation, and reliable synchronization. Future work aims to provide a unified inventory management platform for Vivo’s new retail initiatives.