Scaling Suning’s E‑Commerce for Double‑11: System Splitting and Resilience

System Splitting

Suning’s online business comprises many high‑TPS systems that have been horizontally scaled through continuous splitting and refactoring. Previously, the main site ran on a large IBM‑based B2C platform with massive codebases, long startup times, and frequent downtime during promotions. To improve scalability and reduce risk, the team analyzed core business flows, separated backbone services from peripheral ones, and created independent modules for membership, product, inventory, pricing, cart, transaction, order, and content management, as well as dedicated systems for flash sales, coupons, and marketing.

These smaller, clearly defined services can be deployed independently, allowing faster response to new business requirements and easier onboarding for new engineers.

Basic Platform

After splitting, communication between services and duplication of functionality became challenges. Suning therefore established a foundational R&D center focusing on shared infrastructure such as self‑built CDN, cloud computing, cloud storage, messaging (MYESB), remote call framework (RSF), session sharing, distributed tracing, Redis sharding, database sharding, unified configuration, flow control, monitoring, CI/CD, and big‑data analysis platforms.

The platform also provides security‑related risk control systems. Key components include KVM and Docker middleware for deployment, object and file storage, and monitoring tools that collect real‑time logs (ELK), performance metrics (LogMonitor), and advanced tracing (CloudyTrace).

R&D Process

Suning’s rapid growth led to hundreds of services with varying quality. To ensure consistency, the organization introduced rigorous review checklists and meetings at critical stages: product review, architecture design templates, code inspections, automated quality analysis (Sonar), and a “code fly‑review” involving senior architects and directors to quickly assess core code.

Release checklists require sign‑off from product owners, developers, QA, DBA, operations, and online verification teams, reducing deployment issues.

System Assurance

For Double‑11, Suning focused on two aspects: increasing system load capacity and preparing emergency response plans. Traffic forecasts were broken down to per‑service PV, UV, and peak TPS targets. Systems not meeting these targets were optimized or scaled, prioritizing optimization over additional hardware.

Optimization involved top‑down health checks, architecture reviews, code tuning, and middleware adjustments. Specific improvements included moving user lists from database to Redis for a messaging system, and prioritizing push notifications for key cities.

Middleware tuning covered JVM settings, connection pools, cache strategies, and read/write separation. Load testing identified bottlenecks, sometimes performed on production during low‑traffic periods for realistic results.

Emergency plans consist of blacklists (IP/user), rate limiting (by IP, user, URL), and multi‑level degradation strategies such as disabling non‑critical features, static page rendering, captcha enforcement, extended cache lifetimes, and disabling backend compensation mechanisms. Regular drills are required to keep the plans reliable.