How to Split and Evolve Large-Scale Backend Systems for Scalability and Resilience

System Splitting

When traffic and business complexity grow, a monolithic deployment becomes fragile. The system is decoupled by splitting both the application layer and the database layer. The process follows four progressive steps:

Horizontal scaling : add application instances or clusters and use master‑slave replication for read‑write separation to increase throughput.

Vertical splitting : separate functional modules (e.g., user, product, transaction services) into independent services.

Business splitting : extract business‑level components such as shopping‑cart, checkout, order, and flash‑sale services. Service governance and degradation mechanisms are introduced to handle inter‑service dependencies.

Horizontal partitioning : partition data across multiple nodes (vertical/horizontal table and database sharding) to balance load and isolate hot data.

Typical diagrams illustrate how these splits reduce coupling and improve stability.

Horizontal scaling details

Scale out the application by adding instances or forming a cluster.

Use database master‑slave replication to offload read traffic.

Vertical splitting details

Modules are divided by business function, e.g., separate user, product, and transaction services. Corresponding databases are also split (user DB, product DB, transaction DB).

Business splitting details

Functional granularity is increased: shopping‑cart, checkout, order, and flash‑sale become independent services. Critical paths are cached locally to reduce external calls, and service degradation strategies are applied to keep the overall system alive when a downstream service fails.

Database partitioning

Vertical table splitting: break a large table into several smaller tables based on update or query frequency.

Vertical database splitting: allocate separate databases per business domain (order DB, product DB, user DB).

Horizontal table splitting: distribute rows of a large table across multiple tables.

Horizontal database sharding: further distribute tables across multiple database instances.

Structural Evolution

After splitting, the architecture evolves from a direct‑application‑to‑database model to a layered, service‑oriented design. Remote service calls replace local DB access, requiring service governance, circuit breaking, and degradation handling.

To alleviate database bottlenecks, caching and indexing are introduced. A 2014 upgrade handling 300 million hot records used Solr for indexing (storing only primary keys) and Redis for hot‑data caching with expiration. The same pattern today can be implemented with Elasticsearch + HBase.

Local JVM caches (e.g., for product categories) and ThreadLocal caches further reduce DB hits, cutting latency by ~20 ms and saving thousands of reads per minute.

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

As user‑experience expectations rise, asynchronous processing via message queues decouples front‑end response from back‑end persistence. For example, an order request can publish a message to the order service and immediately return a payment page, while the order service persists data asynchronously.

The evolved architecture separates the business layer (foundation services and composite services) from the data layer (data sources and index caches). Selecting appropriate middleware (e.g., Redis, Solr/Elasticsearch, message queues) is essential to address specific performance and reliability challenges.

Conclusion

System splitting gradually leads to a micro‑service architecture, while structural evolution reflects continuous upgrades in caching, indexing, and asynchronous processing. Technology choices must align with business pain points, team expertise, and resource constraints to achieve a stable, scalable system.