How Suning Scaled Its Membership System for Double‑11: From Legacy POS to Multi‑Active Architecture

Early Offline Architecture Supporting Physical Stores

Suning's initial business focused on offline stores, using a client‑server (CS) architecture where each store ran client software communicating via TCP to an IIS application server, which accessed a Sybase database through ODBC. The server side was split into front‑end modules for client services and back‑end modules for administrators.

Challenges of the Legacy System

As store numbers grew and online sales expanded, the legacy architecture faced performance bottlenecks, limited scalability, and high coupling with other POS modules, leading to long release cycles, inefficient resource usage, and difficulty supporting rapid business changes.

Collaboration with an External Vendor and Birth of the EasyBuy Membership System

To overcome these limitations, Suning partnered with an external vendor, adopting WebSphere Application Server (WAS) and DB2 for a new transaction system. The new membership system used an ESB for real‑time services, MQ for asynchronous communication, and was deployed in a WAS cluster behind an F5 load balancer.

Limitations of the Second‑Generation System

Rapid business growth soon exposed the commercial suite’s rigidity, single‑data‑source constraints, and insufficient horizontal scalability despite read‑write splitting and Redis caching.

Transition to a Vertically Split, Open‑Source Architecture

Suning introduced open‑source technologies and a platform‑centric approach, vertically splitting the membership system into sub‑systems (pre‑combination, level, account profile, account, and reporting) and adopting the Suning Framework (SNF), Data Access Layer (DAL), Remote Service Framework (RSF), ActiveMQ, Kafka, and unified configuration management.

Deployment Details

Front‑end and back‑end applications were deployed in separate Wildfly clusters, using MySQL master‑slave clusters for public, business, and index databases.

Data Migration Strategy Using Spark

Extract full data from DB2 into Hive (A‑type tables).

Classify data into B (invalid), C (clean), and D (filtered) tables.

Insert B‑type data into historical tables of the new system.

For simple C‑type tables, generate SQL inserts directly; for complex ones, transform data into Hive E‑type tables before insertion.

When fixing specific member data, delete related records in the new system, re‑transform, and re‑insert.

System Switch‑Over Process

Old system routes were kept while gradually shifting internal routing to the new system, followed by guiding external systems to call the new APIs. Grey‑scale and functional switches were used in two steps: first switching low‑latency query interfaces, then switching real‑time query and create/update interfaces.

Achieving Multi‑Active Deployment

To avoid single‑site limitations, Suning implemented same‑city dual‑active (双活) architecture, designating a primary data center and a secondary one, deploying the membership services across both, while keeping certain services active only in the primary site.

Future Direction: Cross‑Region Multi‑Active Architecture

Suning plans to extend the dual‑active setup to multi‑region active‑active, synchronizing member data across all data centers, enabling unlimited expansion, and evolving the platform toward a unified Suning membership ecosystem and rentable membership cloud services.