How to Evolve a Monolithic System into a Distributed, Service‑Oriented Architecture

When business complexity and system throughput increase, a monolithic deployment becomes difficult to manage, leading to heavy, fragile systems; therefore, business needs to be partitioned, the system decoupled, and the internal architecture upgraded to improve capacity and robustness.

System Splitting

System splitting can be viewed from a resource perspective as application splitting and database splitting . The evolution steps are horizontal scaling, vertical splitting, business splitting, and finally horizontal splitting again.

1. Horizontal Scaling

Horizontal scaling is the first solution when a system hits a bottleneck. It expands capacity in two ways:

Adding more application instances to form a cluster, thereby increasing overall throughput.

Using master‑slave replication for read/write separation, protecting the database as a critical resource.

2. Vertical Splitting

Vertical splitting truly begins to decompose the system by business function, extracting independent services such as user, product, and transaction systems. Service call governance is introduced to handle inter‑service dependencies, improving stability while increasing overall complexity. Corresponding databases are also split (e.g., user DB, product DB, transaction DB).

3. Business Splitting

Business splitting further divides the application layer by functional characteristics. For example, an e‑commerce transaction system can be split into cart, checkout, order, and flash‑sale services. Specific optimizations, such as caching flash‑sale product data in JVM, reduce external calls and improve performance.

4. Database Splitting

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

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

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

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

Horizontal database‑table partitioning: further split tables across databases.

Structural Evolution

As system complexity and performance requirements grow, internal architecture must evolve. Early systems directly connected applications to databases; after splitting, services depend on remote calls. Caching (e.g., Redis, Solr) and indexing are introduced to alleviate database bottlenecks.

For a 2014 upgrade handling 300 million hot records, the stack chosen was Solr + Redis: Solr stored only indexes, while Redis cached the result set keyed by ID. Misses fell back to the database and refreshed the cache. Today, ES + HBase is also common.

In some cases, thread‑local caches are used for frequently accessed data (e.g., category information) to reduce database reads, improving performance by about 20 ms per operation and cutting tens of thousands of reads per minute.

When external services are unstable, their data can be cached locally to form a closed data loop, reducing reliance on third‑party systems (e.g., caching merchant information for the product service).

As user experience expectations rise, asynchronous processing via message queues becomes essential. For example, an e‑commerce order can be placed by sending a message to the order service while immediately returning the payment page, allowing the order service to persist data asynchronously.

Overall, the system evolves from a simple monolith to a layered, component‑based architecture (often called “mid‑platform” or “front‑platform”), where services are assembled like building blocks to meet rapid business changes.

Conclusion

The system’s structure becomes increasingly complex, but stability and robustness improve. Technology choices must align with business pain points, team expertise, and resource constraints; otherwise, they remain theoretical and ineffective.

These reflections summarize recent years of technical transformation and upgrades; future posts may dive deeper into specific topics.