System Decomposition and Architectural Evolution: Strategies for Scaling E‑commerce Platforms

Xu Xianjun, a JD system architect, explains that as business complexity and system throughput grow, unified deployment becomes difficult, leading to the need for business decomposition, system decoupling, and architectural upgrades to improve capacity and robustness.

1. System Splitting

System splitting can be viewed from a resource perspective as application splitting and database splitting , and from an implementation order as horizontal expansion, vertical splitting, business splitting, and horizontal splitting.

Horizontal Expansion

Increase application instances and form clusters to raise throughput.

Use master‑slave replication for databases to achieve read/write separation.

Vertical Splitting

Vertical splitting separates business functions, extracting modules such as user, product, and transaction systems.

To handle inter‑service dependencies after splitting, service call governance is introduced, improving decoupling and stability while allowing graceful degradation.

Business Splitting

Business splitting divides the application layer by functional characteristics, e.g., separating shopping cart, checkout, order, and flash‑sale systems. For high‑traffic components like flash‑sale, data can be pre‑loaded into JVM cache to reduce external calls.

Database Splitting

Database splitting involves vertical table partitioning, vertical database partitioning, horizontal table partitioning, and horizontal database‑table partitioning.

Vertical table partitioning splits large tables into smaller ones based on update or query frequency.

Vertical database partitioning separates databases by business domains (order, product, user, etc.).

Horizontal table partitioning distributes a large table into multiple tables.

Horizontal database‑table partitioning further separates tables across databases.

Horizontal splitting also includes service layering, turning system services into modular building blocks (e.g., middle‑platform components) that can be combined to meet evolving business needs.

Cold‑hot data separation can be applied, archiving outdated or seasonal data, and focusing recent data in fast storage.

2. Structural Evolution

As system complexity and performance requirements increase, the architecture evolves from direct application‑to‑database connections to remote service calls after splitting.

Performance bottlenecks in databases lead to the introduction of caching and indexing (e.g., Solr+Redis, later ES+HBase) to balance resource usage and speed.

Local JVM caching, ThreadLocal caches, and service‑level data caching reduce repeated database reads, improving latency by around 20 ms and cutting thousands of reads per minute.

When dependent services are unstable, caching their data locally creates a closed data loop, mitigating external risk.

As user experience demands faster response times, asynchronous processing via message middleware (e.g., MQ) decouples order creation from persistence, returning the payment page immediately.

The business layer expands into foundational and composite services, while the data layer splits into data sources and index caches, requiring careful integration of technologies and middleware.

3. Conclusion

System structures become increasingly complex, enhancing stability and robustness; technology choices must align with business pain points, technical expertise, and resource constraints to avoid impractical solutions.

The author summarizes recent technical transformations and upgrades, noting that system splitting ultimately leads to micro‑services, and structural evolution represents ongoing architectural upgrades.