System Splitting and Architectural Evolution: Strategies for Scaling and Decoupling

As business complexity and system throughput increase, unified deployment becomes difficult and inter‑module interference makes the system heavy and fragile; therefore, splitting business functions, decoupling architecture, and upgrading internal structures are needed to improve capacity and robustness.

1. System Splitting

System splitting can be viewed from a resource perspective (application splitting and database splitting) and from the order of adoption (horizontal scaling, vertical splitting, business splitting, and further horizontal splitting).

Figure 1: Principles of System Decomposition

Horizontal Scaling

Horizontal scaling is the first‑line solution when a system hits a bottleneck, mainly achieved by adding application instances (clustering) and using master‑slave replication for read/write separation in databases.

Vertical Splitting

Vertical splitting separates the system by business functions, creating independent subsystems such as user, product, and transaction services. Service call governance is introduced to handle inter‑service dependencies, improving decoupling and stability.

Business Splitting

Business splitting divides the application layer by functional characteristics, e.g., separating shopping cart, checkout, order, and flash‑sale modules. For high‑traffic scenarios like flash sales, data can be pre‑loaded into JVM caches to reduce external calls.

Database Splitting

Vertical table splitting: split a large table into smaller tables based on update or query frequency.

Vertical database splitting: create separate databases per business domain (e.g., order DB, product DB, user DB).

Horizontal table splitting: partition a large table into multiple tables.

Horizontal database‑table splitting: further partition tables across databases.

Figure 2: Product Table Splitting

Figure 3: Database and Table Partitioning

Horizontal Splitting

Service layering turns system services into modular building blocks, separating functional and non‑functional components. Large‑scale platforms (mid‑platform, front‑platform) act as component libraries that can be composed dynamically, such as assembling product details on an e‑commerce page.

Cold‑hot data separation can also be applied at the database level, archiving outdated or seasonal items while keeping recent data readily accessible.

2. Structural Evolution

Structural evolution is driven by increasing system complexity and performance requirements. Early architectures directly linked applications to databases; after splitting, services depend on remote calls, leading to the introduction of caching and indexing to alleviate database bottlenecks.

Figure 4: Early Application Structure

In a 2014 upgrade handling 300 million hot records, the stack used Solr + Redis, storing only indexes in Solr and caching results in Redis with expiration policies; missed cache entries fell back to the database. Modern alternatives include ES + HBase.

Figure 5: Adding Cache and Index

Frequently accessed data can also be cached in JVM memory or thread‑local storage to further reduce latency, as demonstrated by a 20 ms performance gain and a reduction of ~10,000 reads per minute for product validation.

Figure 6: Adding Local Cache

When dependent services are unstable, treating them as data sources and caching their responses (e.g., product‑service caching merchant info) reduces external risk.

Figure 7: Remote Service Evolving into Data Source

As user experience demands faster response times, asynchronous processing via message queues (e.g., order creation) decouples front‑end actions from back‑end persistence.

Overall, the system architecture becomes more complex but also more stable; technology choices must align with business pain points, team expertise, and resource constraints.

3. Conclusion

The gradual increase in structural complexity improves stability and robustness; however, technology selections must be realistic and tailored to specific challenges rather than generic hype.