System Splitting and Architectural Evolution: From Monolith to Distributed Services
The article reviews how increasing business complexity and throughput demands drive the need to split applications and databases, adopt horizontal and vertical scaling, implement business and service-level partitioning, and evolve system architecture toward micro‑services, caching, and asynchronous processing.
Recently I gave an internal department talk for newcomers, sharing how a system evolves into a distributed, service‑oriented architecture based on my own experience.
As business complexity and system throughput grow, unified deployment becomes difficult, modules interfere with each other, and the system becomes heavy and fragile; therefore, business needs to be split, 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, and from a chronological perspective as horizontal scaling, vertical splitting, business splitting, and horizontal splitting.
1. Horizontal Scaling
Horizontal scaling is the initial solution for bottlenecks, achieved by adding application instances to form a cluster and by using master‑slave replication for read/write separation in databases.
2. Vertical Splitting
Vertical splitting separates the system by business functions, creating independent user, product, transaction services, etc., and introduces service governance to handle inter‑service dependencies, improving decoupling and stability; corresponding databases are also split accordingly.
3. Business Splitting
Business splitting divides the application layer by functional characteristics, e.g., separating shopping cart, checkout, order, and flash‑sale modules; performance‑critical modules may cache data in JVM to reduce external calls.
Database splitting follows steps: vertical table partitioning, vertical database partitioning, horizontal table partitioning, and horizontal database‑table partitioning.
Vertical table partitioning splits a large table into smaller ones based on update or query frequency.
Vertical database partitioning separates databases by business, such as order, product, and user databases.
Horizontal table partitioning divides a large table into multiple tables.
Horizontal database‑table partitioning further splits tables across databases.
4. Horizontal Splitting
Service layering turns system services into modular building blocks, enabling front‑end composition of components (e.g., product page showing image, price, stock, coupons) and supporting middle‑platform architectures.
Database hot‑cold data separation can archive outdated items and keep recent data readily accessible.
Architectural Evolution
As system complexity and performance requirements increase, internal architecture upgrades become necessary.
Early systems directly connected applications to databases; after splitting, services depend on remote calls.
To address database bottlenecks, caches (e.g., Redis) and indexes (e.g., Solr) are introduced; a typical 2014 upgrade for 300 million hot records used Solr + Redis, storing only IDs in Solr and full data in Redis with expiration, falling back to the database when cache misses occur.
Frequently accessed data can be cached in JVM (e.g., category information) or using ThreadLocal for per‑thread caching, with careful handling of expiration and validity.
When dependent services are unstable, creating a local cache of their data (e.g., product service caching merchant info) reduces external risk.
Increasing user‑experience expectations drive asynchronous processing via message middleware; for example, an e‑commerce order is placed by sending a message to the order service while immediately returning the payment page.
The business layer now includes foundational and composite services, while the data layer comprises data sources, indexes, and caches, requiring effective integration of technologies and middleware.
Conclusion
System structures become increasingly complex, improving stability and robustness; technology choices must align with business pain points, technical expertise, and resource constraints to avoid impractical solutions.
This summary reflects several years of personal experience with technical transformations and upgrades, with opportunities for deeper dives into specific topics.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.