Li Ning is one of China's leading sportswear brands, operating an omnichannel retail business that generates over 200,000 e-commerce orders per day across marketplaces, social commerce, its own app, and an offline POS network. To carry that growth, the company modernized the database tier beneath its Order Management System (OMS) — the platform that coordinates order processing, inventory management, and sourcing and allocation — moving it from RDS MySQL onto OceanBase. The new data architecure now carries promotional peaks above 50,000 orders a minute on 80% less storage, at 40% lower database TCO.

Challenge

Li Ning's OMS ran on RDS MySQL in a one-primary, one-replica topology. The primary carried all transactional reads and writes — order creation, allocation-ticket generation, and other core operations — while the replica synced to a local Greenplum (GP) cluster for BI reporting and business monitoring, and a separate on-premise MySQL instance handled backups. Inventory ran on a two-tier store of its own: a cluster of eight Redis instances partitioned by region, each managing the stock for a set of warehouses, backed by a local cache.

This setup functioned adequately at moderate scale, but as Li Ning's e-commerce revenue grew to nearly 30% of total group revenue — with peak order rates surpassing 50,000 per minute during major promotions — the architecture began to strain:

• Cross-region inventory checks dragged at peak. With stock partitioned across eight regional Redis instances, fulfilling an order that drew inventory from more than one region meant cross-checking multiple instances. At high concurrency during promotions, that cross-region validation slowed the whole system.
• Promotion scaling meant long maintenance windows. Expanding capacity for a major promotion required extended maintenance windows, putting system continuity at risk during the very periods that demanded the most uptime.
• A single instance failure could black out a region's inventory. Losing any one of the eight Redis instances rendered that region's stock data inaccessible — degrading the customer experience and disrupting omnichannel inventory allocation.
• BI reporting competed with live order traffic. The replica feeding the Greenplum BI cluster lagged the primary by minute-level, so real-time reporting pulls fell back on the primary and contended with transactional load.

With daily order volumes exceeding 200,000 as the new baseline and core business tables surpassing the hundred-million-row mark, Li Ning's technology team recognized the need for a fundamental modernization of the database tier.

Database Selection

Li Ning launched a formal database evaluation. The brief was explicit: the next architecture had to fit current scale and leave room for the trajectory implied by the company's "single brand, multiple categories, multiple channels" strategy. The team distilled it into three requirements:

• Distributed architecture with transparent scaling. Horizontal scale-out without application changes, automatic sharding and load rebalancing, and seconds-level multi-zone failover — so that a single-node outage during a promotion never becomes a regional inventory blackout.
• Multi-cloud native. Containerized deployment, native elastic scaling, and multi-cloud portability for data residency and disaster-recovery posture.
• Lower TCO at higher performance. Not "cheaper at lower performance" — the goal was to raise throughput while lowering total cost, primarily through storage compression and instance consolidation.

After multiple rounds of evaluation, Li Ning selected OceanBase. Following a multi-month implementation, the new system went live ahead of the mid-year shopping festival — a peak sales event that puts the order system under its heaviest load of the season.

Solution

The migration moved the OMS's core workloads — order processing, inventory, sourcing, and fulfillment allocation — onto a single OceanBase cluster, consolidating the former standalone MySQL instances into one multi-tenant deployment. Five OceanBase capabilities did the load-bearing work:

Elastic distributed scaling for promotion peaks. OceanBase's native distributed architecture scales out horizontally and transparently to the application, so the OMS can absorb promotional surges without re-architecting or pausing for maintenance windows.

Inventory becomes a transactional part of the database. OceanBase's strong-consistency distributed transactions hold inventory state in the database itself, so stock is updated transactionally rather than reconciled across a regional cache layer, and cross-warehouse sourcing runs as a query inside one system instead of a fan-out across instances.

Multi-zone replicas keep BI off the order path. OceanBase replicates across availability zones with Paxos-based log replication, keeping follower replicas within seconds of the leader. BI and reporting read from a dedicated replica rather than falling back on the primary, so analytics no longer contend with live order traffic.

Row-column hybrid storage with LZ4 compression. OceanBase's LSM-tree engine compacts baseline data with columnar encoding and general-purpose compression, shrinking the on-disk footprint without trading away query latency on the read-heavy inventory path.

Multi-tenant consolidation. Development, testing, and production — previously separate MySQL instances, each with its own operational overhead — run as tenants in a single cluster, each with dynamically resizable CPU, memory, and IOPS quotas over shared compute and storage.

Results

OceanBase's impact was validated under the most demanding conditions — the mid-year shopping festival — and confirmed across multiple quarters of continuous production since.

• Handled peak order volume with room to spare. The system sustained peaks above 50,000 orders per minute during the festival with no application changes and no manual intervention. Peak CPU fell from 90% to 75%, and steady-state CPU settled into the 40–55% range — turning what had been an uncomfortable ceiling into the headroom needed to absorb the unplanned, from a viral post to a flash restock, without triggering alerts.
• Kept inventory accurate under peak load. Five billion daily inventory updates now persist in real time with an inventory error rate below 0.01%, and cross-warehouse reallocation completes in seconds.
• Cut slow queries by 60%. The improvement comes largely from the row-column hybrid storage paying off on the read-heavy inventory-check path, where LZ4-compressed columnar baseline data scans dramatically less I/O than the equivalent MySQL row-scan.
• Took BI off the primary's back. Primary-to-replica sync delay fell from minute-level to second-level, so BI reporting reads near-real-time data without falling back on the primary.
• Shrank the dataset 5× on disk. LZ4 compression with row-column hybrid storage cut the dataset from 5 TB to 1 TB.
• Lowered database TCO by 40%. The savings come mainly from two drivers: 80% less storage, and multi-tenant consolidation that collapses redundant instances and trims combined hardware, licensing, and operations costs.