Evolution of the PLUS Membership Partner System Architecture: Design Patterns, Sharding, and Cluster Separation

A good system architecture evolves over time; when a system first launches it cannot anticipate all performance, scalability, and security requirements, but as business demands and traffic grow, the architecture continuously matures, similar to the evolution of large sites like Facebook and Taobao.

The PLUS membership partner business, with an increasing number of partners, shifted from full regression testing to targeted development; this article shares best‑practice experience of the system’s architectural evolution.

In March 2018 PLUS first partnered with iQIYI, followed by Zhihu in May 2018 and Tencent Video in June 2019. All partners use the same API, requiring the business layer to differentiate types, which forces changes to shared logic whenever a new partner is added, increasing development and testing effort.

The evolution process began with extensive research on design patterns and business logic to identify commonalities and differences among partners, enabling top‑down routing adaptation and the use of mature middleware to solve performance issues.

1. Command Pattern + Template Pattern – Requests are encapsulated as objects, decoupling callers from receivers. The top‑level Command interface defines execute(), while BasicCommand implements the main flow (parameter validation, packaging, anti‑frequency, authentication, pre‑ and post‑processing). BasicForeignCommand provides default implementations for extensions.

2. Strategy Pattern + Container Extension – The Context hides strategy selection from clients. Spring’s ApplicationContextAware retrieves beans representing partner‑specific strategies, stored in a map keyed by partner identifier plus method name. A base strategy class provides common logic, while subclasses implement partner‑specific behavior.

3. Monitoring and Exception Handling – Spring AOP is used to separate cross‑cutting concerns. Interface annotations trigger around‑advice that automatically reports to UMP, and exceptions are mapped to specific error codes, providing unified error management.

4. Sharding – The original single‑database design caused bottlenecks during high‑traffic promotions. Sharding‑JDBC middleware was introduced to implement database and table partitioning with a custom starter defining eight master and eight slave data sources and flexible routing rules, achieving up to 100,000 TPS.

5. Cluster Separation + Optimization – Traffic is split into two clusters (PLUS‑to‑partner and partner‑to‑PLUS). This “divide and conquer” approach yields lightweight, responsibility‑focused clusters and clearer monitoring. Caching hot data (following the 80/20 rule) further improves performance and user experience.

The architecture evolution is a continuous refactoring and decoupling effort that now incorporates interaction design, user experience, technical architecture, business processes, data models, and functional design. The platform supports multiple partners with a workload reduced to one‑tenth of the original, offering high cohesion, loose coupling, and clear responsibility separation. Future development will continue to follow strict standardization of processes, data, and technology.