Evolution and Practice of Suning E‑commerce Inventory System Architecture for Double 11 Peak

The inventory system is a core component of Suning's e‑commerce platform, providing real‑time stock queries, locks, and updates for both online and offline channels, and supporting various business scenarios such as procurement, sales, logistics, and data analytics.

Key challenges include handling hotspot contention during flash‑sale events, improving inventory turnover, preventing oversell, and ensuring unlimited scalability despite bottlenecks like database and queue connection limits.

Architecture evolution is divided into four stages: (1) 2005‑2012 – early e‑commerce with WCS/POS + SAP; (2) 2012‑2013 – O2O era with front‑mid‑back separation and an independent SAP inventory module; (3) 2013‑2016 – multi‑platform sales, building a Java‑based self‑developed inventory system; (4) 2016‑present – multi‑active, multi‑datacenter deployment using a large‑scale database distribution engine.

The early architecture suffered from tight coupling, vendor lock‑in, single‑database limits, and poor extensibility, prompting a front‑mid‑back separation that isolated transaction services (CIS, GAIA, CIMS, AIMS) from management services and enabled independent scaling.

The self‑developed inventory architecture introduces a unified routing layer (CIS), high‑performance transaction services (GAIA for self‑stock, CIMS for third‑party stock, AIMS for flash‑sale stock), and a data layer split into public, business, and log databases, employing horizontal sharding and eventual consistency to handle distributed transactions.

Flash‑sale inventory adopts cache‑based transaction processing, activity‑specific isolation, and WAF/IP‑UA controls to mitigate massive concurrent requests and bot traffic, using Redis Lua scripts for atomic stock deduction and asynchronous DB updates for replenishment.

To address scalability and fault‑tolerance, the system implements unitization (closed, highly available, infinitely extensible units) and a multi‑active deployment where each data center runs an independent inventory service with intelligent stock allocation and cross‑datacenter backup.

Preparation for Double 11 includes capacity estimation (TPS targets), machine scaling (JBoss clusters, MySQL sharding), flow‑control and degradation policies, extensive performance testing (single‑service and end‑to‑end), health checks (resource usage, HA verification), and incident/version retrospectives to eliminate repeat failures.