Backend Development 9 min read

Evolution of E-commerce System Architecture

This article outlines the progressive evolution of e‑commerce system architecture from a monolithic 1.0 design through layered scaling, read/write separation, CDN caching, sharding, and finally unit‑based modularization, highlighting the performance bottlenecks and solutions at each stage.

Top Architect
Top Architect
Top Architect
Evolution of E-commerce System Architecture

In this article, a senior architect walks through the architectural evolution of an e‑commerce website, illustrating how the system adapts to increasing traffic and complexity.

1.0 Era

The initial monolithic web project contains all modules and a single database. As traffic grows, the Tomcat connection limit and thread context switching become bottlenecks, prompting horizontal scaling of web servers.

2.0 Era

Further traffic increase shifts the bottleneck to the database, limited by maximum connections and large table size. Solutions include read/write separation with master‑slave replication and caching, or vertical splitting of business modules when consistency requirements are high.

Database connection limit (e.g., 8000 total, 40 per server) caps the number of web servers.

Large tables increase query latency; index optimization is only a temporary fix.

3.0 Era – Read/Write Separation

Even with vertical architecture, maintaining a single project for all business logic hampers rapid iteration. The architecture evolves to separate large modules, preparing for further scaling.

4.0 Era – Business Unit Splitting

To improve user experience, a CDN caches static content, reducing latency. As data volume grows to tens of millions of rows, single‑database performance degrades, leading to sharding (database and table partitioning) to distribute load.

Further scaling introduces dual‑data‑center deployment with dedicated links, but cross‑center database calls still add latency, and connection limits persist.

5.0 Era – Unit‑Based Architecture

Traffic is routed from the entry layer to different units based on rules (e.g., user ID). Each unit is highly cohesive, containing core services and matching data‑sharding logic, alleviating database connection bottlenecks while still requiring some cross‑unit calls for shared services.

Reference Articles

Li Zhihui, "Large‑Scale Website Architecture"

https://blog.csdn.net/caoyuanyenang/article/details/86943397

https://www.cnblogs.com/lfs2640666960/p/9021205.html

http://www.hollischuang.com/archives/728

Readers are encouraged to discuss and share viewpoints, and to contact the author for further communication.

e-commerceSystem Architecturecdndatabase shardingbackend scalingunit-based design
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.