How to Split and Evolve Complex Systems: From Horizontal Scaling to Microservices

As business complexity and system throughput increase, deploying all functions together becomes difficult, causing modules to interfere with each other and making the system bulky and fragile. To improve capacity and robustness, the business must be split, the system decoupled, and the internal architecture upgraded.

System Splitting

System splitting is divided by resources into application splitting and database splitting . By implementation order it includes horizontal scaling, vertical splitting, business splitting, and horizontal splitting.

1. Horizontal Scaling

Increase application instances and form clusters to raise throughput.

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

2. Vertical Splitting

Vertical splitting truly begins system decomposition, separating business functions such as user, product, and transaction systems. Service governance is introduced to handle inter‑service dependencies, increasing complexity but achieving basic decoupling and higher stability; proper degradation prevents cascading failures.

Corresponding databases are also split into user, product, and transaction databases.

3. Business Splitting

Business splitting targets the application layer, dividing features like shopping cart, checkout, order, and flash‑sale modules. For flash‑sale scenarios, product data can be pre‑loaded into JVM cache to reduce external calls and improve performance, easing pressure on the product system.

Database splitting follows several steps: vertical table, vertical database, horizontal table, and horizontal database/table.

Vertical Table – split a large table into smaller ones based on update or query frequency.

Vertical Database – split databases by business, e.g., separate order, product, and user databases.

Horizontal Table – divide a large table into multiple tables to handle massive data volume.

Horizontal Database/Table – further split tables for finer granularity.

4. Horizontal Splitting

Service layering turns system services into building blocks, separating functional and non‑functional components and combining them into middle‑platform or front‑platform architectures. The middle platform provides reusable services, while the front end composes these blocks to quickly respond to business needs, such as displaying product images, price, stock, coupons, or recommendations on an e‑commerce product page.

Databases can also separate hot and cold data; outdated or seasonal items are archived, and older order data is accessed less frequently, allowing different storage strategies.

Structural Evolution

Structural evolution is driven by increasing system complexity and performance requirements, prompting internal architecture upgrades.

Early systems directly linked applications to databases. After splitting, functions rely on remote calls to other services.

Higher performance demands lead to caching and indexing solutions. For example, a 2014 upgrade handling 300 million hot records used Solr for indexing and Redis for caching, storing only primary keys in Solr and keeping hot data in Redis with expiration policies; missed cache hits fall back to the database. Modern alternatives include ES + HBase.

Frequently accessed data can also be cached in JVM memory (e.g., category information) or using ThreadLocal for per‑thread caches, improving performance by reducing database reads.

When dependent external services are unstable, their data can be cached locally to form a closed data loop, reducing risk from third‑party failures.

Increasing user‑experience expectations push systems toward asynchronous processing via message queues; for example, an e‑commerce order can be placed by sending a message to the order service while immediately returning a payment page.

Overall, the business layer expands into foundational and composite services, while the data layer splits into data sources and indexed caches; effective technology and middleware integration is essential to address diverse system challenges.

In conclusion, as system structures become more complex, stability and robustness improve, but technology choices must align with business pain points, technical expertise, and resource constraints; otherwise they remain impractical.