System Splitting and Architectural Evolution: Strategies for Scaling and Decoupling

As business complexity and system throughput increase, unified deployment becomes difficult, leading to heavy and fragile systems; therefore, business decomposition, system decoupling, and architectural upgrades are needed to enhance capacity and robustness.

1. System Splitting

System splitting can be viewed from a resource perspective as application splitting and database splitting, and from an implementation order as horizontal scaling, vertical splitting, business splitting, and horizontal splitting.

Figure 1: System Decomposition Principles

Horizontal Scaling

Horizontal scaling is the initial solution, expanding both application instances (clustering) and database read/write separation via master‑slave replication.

Vertical Splitting

Vertical splitting separates functional modules such as user, product, and transaction systems, introducing service governance to handle inter‑service dependencies and improve stability.

Business Splitting

Business splitting divides the application layer by functional features (e.g., shopping cart, checkout, order, flash‑sale). For flash‑sale systems, product data can be pre‑loaded into JVM cache to reduce external calls.

Database Splitting

Database splitting includes vertical table partitioning, vertical database partitioning, horizontal table partitioning, and horizontal database‑table partitioning.

Figure 2: Product Table Splitting

Vertical database partitioning creates separate databases for orders, products, users, etc.; horizontal table partitioning splits large tables into multiple tables; horizontal database‑table partitioning further refines the split.

Figure 3: Database and Table Partitioning

Horizontal Splitting

Service layering turns system services into modular building blocks, enabling front‑end composition (e.g., product page showing image, price, stock, coupons) and back‑end middle‑platform components.

Database hot‑cold data separation can archive expired or seasonal items, reducing storage pressure for infrequently accessed historical data.

2. Structural Evolution

As system complexity and performance demands grow, internal architecture upgrades become necessary. Early systems directly linked applications to databases; after splitting, remote calls appear.

Figure 4: Early Application Structure

To address database bottlenecks, caches (e.g., Redis) and indexes (e.g., Solr) are introduced. In a 2014 upgrade handling 300 million hot records, Solr stored only indexes while Redis cached the actual data, reducing I/O and improving performance.

Figure 5: Adding Cache and Index

Frequently used data can be placed in JVM cache (e.g., category information) or ThreadLocal cache, improving response time by about 20 ms and reducing database reads by tens of thousands per minute.

Figure 6: Adding Local Cache

When dependent services are unstable, caching their data locally turns them into reliable data sources, reducing external risk.

Figure 7: Remote Service Evolving into Data Source

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

Figure 8: Complex Structure

3. Conclusion

System architecture becomes increasingly complex, improving stability and robustness; technology choices must align with business pain points, team expertise, and resources to avoid unrealistic solutions.

The author’s recent experience with architectural upgrades is summarized, with future detailed sharing planned; system splitting ultimately leads to microservices, and structural evolution reflects ongoing technical upgrades.