How to Split Complex Systems and Evolve Architecture for Scalable Micro‑services

System Splitting Overview

As business complexity and system throughput increase, unified deployment becomes difficult, and tightly coupled modules make the system heavy and fragile. To improve capacity and robustness, the system must be split, decoupled, and its internal architecture upgraded.

1. Horizontal Scaling

Increase application instances and form clusters to raise overall throughput.

Use master‑slave database replication for read/write separation, protecting the most critical resource.

2. Vertical Splitting

Separate the system by business functions, creating dedicated services such as user, product, and transaction systems.

3. Business Splitting

At the application layer, split functionalities like shopping cart, checkout, order, and flash‑sale modules. For high‑traffic scenarios (e.g., flash sales), preload product data into JVM cache to reduce external calls and improve performance.

4. Database Splitting

Database partitioning can be performed in several steps:

Vertical partitioning: divide a large table into smaller tables based on update or query frequency.

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

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

Horizontal sharding: further split tables across multiple databases for finer granularity.

Structural Evolution

When system complexity grows and performance requirements rise, internal architecture must be upgraded. Early systems directly connected applications to databases; after splitting, services depend on remote calls.

To address database bottlenecks, caches and indexes are introduced. A typical solution combines Solr (or ES) for indexing with Redis for key‑value caching. In a 2014 upgrade handling 300 million hot records, only primary keys were stored in Solr, while full data resided in Redis with expiration; cache misses fell back to the database.

For frequently accessed data, JVM‑level caching (or ThreadLocal) can further reduce database calls. Example: caching category information in JVM cut per‑minute product reads by nearly ten thousand, improving response time by ~20 ms.

When dependent services are unstable, treat them as data sources and cache their results, turning remote services into reliable data providers and isolating external failures.

As user experience demands faster response, asynchronous messaging becomes essential. In e‑commerce order processing, the front‑end returns the payment page immediately while the order service saves data asynchronously via a message queue.

Overall, the system evolves from a simple monolith to a complex, layered architecture comprising foundational services, composite services, data sources, and indexed caches, all coordinated to meet performance and reliability goals.

Conclusion

System complexity gradually increases, but stability and robustness improve through careful technology selection aligned with business pain points, technical expertise, and resource constraints. The final stage of system splitting leads to micro‑services, while structural evolution reflects continuous technical upgrades.