How Vivo Scaled Its E‑Commerce Inventory: Architecture & High‑Concurrency Solutions

1. Business Background

Inventory system is the core of e‑commerce product management. Vivo’s original inventory was tightly coupled with the product system; as business logic grew, the inventory service was split and new capabilities such as physical stock, flash‑sale stock, logistics timing, shipping limits, and multi‑warehouse management were added.

2. System Architecture Design

Vivo’s large‑scale e‑commerce inventory is divided into three layers:

Warehouse layer – physical warehouses (self‑operated, third‑party) and WMS/ERP systems.

Scheduling layer – stock dispatch and order fulfillment.

Sales layer – official store, physical stores, and third‑party distribution channels.

The official store’s inventory resides in the sales layer and interacts with the scheduling layer.

3. Business Architecture

3.1 Stock Types & Warehouse Management

The system defines four stock categories:

Sellable stock – ordinary SKU‑level inventory configured by operations.

Physical stock – real‑world inventory synchronized from warehouse systems, detailed per warehouse.

Pre‑reserved stock – reserved when an order is placed and released after shipping; used to monitor ordered‑but‑not‑shipped quantity.

Activity stock – inventory for flash‑sale or promotional events.

Warehouse information, split‑warehouse strategy, and real‑time physical stock are maintained in the inventory center.

3.2 Inventory Flow

Two main operations drive stock changes: forward deduction and reverse rollback.

Forward deduction can be performed either at order time or at payment time. Order‑time deduction provides real‑time stock reduction and avoids payment‑time failures but can be abused by malicious bulk orders; payment‑time deduction prevents abuse but may block payment when demand exceeds stock. Vivo adopts order‑time deduction with a 15‑minute hold, releasing the stock if the order remains unpaid.

Reverse rollback uses stock‑change logs to revert sellable and pre‑reserved stock when a refund is requested before shipment; after shipment, stock is not rolled back.

4. Technical Key Points

4.1 Deduplication of Stock Deduction

Duplicate deductions caused by repeated submissions are prevented by greying out the submit button, guaranteeing idempotent APIs (using a unique order token or sequence number), and logging each deduction. The system adds the order serial number to the deduction request and checks for an existing log before performing the operation.

4.2 Anti‑Oversell & High‑Concurrency Strategies

For regular channels with low traffic, direct database deduction using optimistic locking is employed. The SQL checks that remaining stock is sufficient before updating.

sql: update store set store = store - #{deductStore} where (store-#{deductStore}) >= 0

Advantages: real stock deduction, no oversell, optimistic lock ensures consistency, transaction guarantees rollback. Drawbacks: row‑level lock can become a performance bottleneck under high concurrency, and each deduction is a write‑heavy DB operation.

High‑traffic flash‑sale scenarios use a Redis + Lua script to perform single‑threaded stock updates, followed by one of two schemes:

Scheme 1: Direct database deduction with strict pre‑validation and read‑write separation.

Scheme 2: Redis deduction, then insert a stock‑task record into the database within a transaction; an asynchronous worker later syncs the task to the actual stock tables, ensuring eventual consistency.

Scheme 2 avoids oversell while keeping DB load low; it includes a delayed‑retry mechanism for rollback in case the async update lags.

4.3 Hotspot Mitigation

Two hotspot types are addressed:

Database row lock on popular items – mitigated by sharding a SKU’s stock across multiple rows and randomly selecting a row for each deduction.

Redis single‑node overload – mitigated by dispersing Redis keys across multiple shards when syncing stock data.

4.4 Stock Synchronization

Physical stock sync with warehouse systems supports both scheduled full‑batch sync and on‑demand SKU sync.

Product‑system stock sync uses the in‑house CDC platform “Luban”. Binlog changes from the inventory DB are captured, filtered, published to MQ, and consumed by the product system to keep both sides consistent.

5. Summary & Outlook

The inventory system has been split into independent services, adding flexible stock types, deduplication, high‑concurrency handling, hotspot mitigation, and robust synchronization mechanisms, thereby empowering business growth. Future work aims to provide a unified inventory platform for Vivo’s new retail ecosystem.