How a Lightweight Redis‑Based Inventory Architecture Boosts High‑Traffic E‑Commerce Systems

Background

The rapid development of the logistics industry and the rollout of integrated supply‑chain models have put enormous pressure on system throughput and stability, especially for inventory, which is the core of the supply chain. Over the past three years, merchant onboarding grew 37.64% YoY, product varieties 53.66% YoY, SKU count 46.43% YoY, and warehouse count 18.87% YoY. During major sales events, minute‑level traffic spikes of up to 75% caused order backlogs, with inventory pre‑allocation and throughput being major bottlenecks. The current MySQL‑based inventory pre‑allocation cannot keep up with the growing integrated supply‑chain and key‑account merchants, and future 3‑5‑year growth is expected to increase traffic 5‑10×, making a lightweight inventory architecture essential.

Architecture Principles

The architecture is problem‑oriented, aiming to solve high concurrency, system stability (disaster recovery), and data consistency for both non‑functional and functional requirements.

System Design

Design Idea

Identify the current inventory system bottleneck: write‑heavy traffic makes the database the choke point.

Replace the database with a high‑concurrency component (Redis) to alleviate the bottleneck.

When using Redis, address oversell prevention and ensure eventual consistency via asynchronous writes back to the database.

Overall Design

Load‑bearing part : Move the high‑throughput pre‑allocation logic from MySQL to Redis, leveraging Redis’s fast read/write to handle peak traffic.

Data write‑back : Redis only holds temporary data for accounting; final consistency is achieved by writing back to MySQL, sacrificing short‑term consistency for peak‑shaving.

Differential part : The new design switches data handling to Redis via configurable sharding, using Redis’s high read/write performance for load shedding.

Detailed Design

Inventory Initialization : Use Redis

WATCH

command to implement a lock and avoid race conditions.

LUA Executor : Package atomic operations into Lua scripts to reduce network overhead.

Compensation Mechanism : On any business exception, trigger a reverse operation; if the reverse fails, submit an asynchronous compensation task; if that also fails, rely on monitoring to scan and correct abnormal inventory records.

Data Structure

Inventory Record Index : {deptNo|goodsNo|warehouseNo}|stockStatus|stockType|goodsLevel

hashTag : Same as the index above.

Usable Stock Key : usableKey:{Inventory Record Index}

Subtract Stock Key : usableSubtractKey:{Inventory Record Index}

Pre‑allocation Anti‑duplicate Key : operateKey:{Inventory Record Index:orderNo}

Rollback Anti‑duplicate Key : rollbackOperateKey:{Inventory Record Index}

Shortage Pre‑allocation Key : ullageOperateKey:{Inventory Record Index}

Stock Deduction Record : hSetrecord:{Inventory Record Index}

Redis & DB Consistency

Compare Redis and replica DB data; if differences exist, verify the primary DB.

During comparison, lock DB SKU rows (FOR UPDATE) and ensure DB usable stock equals Redis usable stock plus Redis pre‑allocation.

If discrepancies are found, trigger alerts, expire the cached available quantity, and correct the pre‑allocation.

Disaster Recovery Plan

The system adopts dual‑Redis deployment, fault‑tolerant monitoring, and graceful degradation. In case of three consecutive failures, data loss is tolerated. Traffic distribution is prepared for peak events such as the 618 promotion, with mechanisms to handle data inconsistency across multiple merchants.

Performance Results

During the 2023 618 promotion, the new Redis‑based architecture achieved significant throughput improvement, handling the massive traffic surge without order backlogs.

Cold and Hot Data

OMS inventory cold‑hot switch mechanism.

Key monitoring for pre‑allocation architecture upgrade.

Merchant segmentation for inventory pre‑allocation upgrades.

Detailed merchant lists for upgraded and non‑upgraded merchants.

Future Work

The article concludes with a note that the second phase will continue to share batch‑stock and in‑memory model details.