How to Split Complex Systems and Evolve Architecture for Scalability

1. System Splitting

As business complexity and system throughput increase, unified deployment becomes difficult and inter‑module interference makes the system heavy and fragile, so splitting and decoupling are required to improve capacity and robustness.

1.1 Horizontal Scaling

Increase application instances and form clusters to raise overall throughput.

Use master‑slave database replication for read/write separation, protecting the primary data store.

1.2 Vertical Splitting

Separate the system by business functions, creating dedicated services such as user, product, and transaction systems. Service call governance is introduced to handle inter‑service dependencies, improving stability while requiring proper degradation strategies.

1.3 Business Splitting

At the application layer, split by functional features—for example, a flash‑sale system isolates shopping‑cart, checkout, order, and seckill modules. Frequently accessed product data can be pre‑loaded into JVM cache, reducing external calls and boosting performance.

1.4 Database Splitting

Database sharding follows four main steps: vertical table, vertical database, horizontal table, and horizontal database‑table.

Vertical table: split a large table into several smaller ones based on update or query frequency.

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

Horizontal table: partition a large table into multiple tables to handle massive data volume.

Horizontal database‑table: further divide tables across multiple databases for deeper scaling.

2. Structural Evolution

When system complexity grows and performance requirements rise, internal architecture must be upgraded. Early systems directly linked applications to databases; after splitting, services depend on remote calls. Caching and indexing are introduced to alleviate database bottlenecks.

In a 2014 upgrade handling 300 million hot records, the stack used Solr + Redis: Solr stored only indexes, Redis cached primary keys and hot data with expiration, and a fallback to the database occurred on cache miss. Modern alternatives include ES + HBase.

Frequently accessed data may be placed in JVM cache (e.g., category information) or ThreadLocal cache for per‑thread reuse, with careful handling of cache invalidation.

When dependent third‑party services are unstable, their data can be cached locally, turning the remote service into a reliable data source and reducing external risk.

As user experience expectations rise, asynchronous processing via message middleware (e.g., order creation via messaging) decouples front‑end response from back‑end persistence, improving perceived performance.

3. Final Thoughts

System complexity inevitably grows, but stability and robustness improve with proper splitting, caching, and architectural upgrades. Technology choices must align with business pain points, team expertise, and resource constraints; otherwise, they become impractical and overly generic.