Evolution of Large‑Scale E‑commerce Backend Architecture: From Single Server to Distributed Systems

The article uses Taobao’s architecture as a case study to illustrate how large‑scale e‑commerce backends grow from a simple single‑server setup to a complex, highly available distributed system.

1. Single‑Server (All‑in‑One) : Initially, file, database, and application services run on one machine, which quickly becomes a bottleneck as traffic grows.

2. Separation of Data and Application Services : Data services are moved to dedicated servers with larger disks, while application servers receive more CPU and memory, improving availability and performance.

3. Caching Layer : Introduces local, remote, and distributed caches to store the hot 20% of data (the 80/20 rule), dramatically reducing latency.

4. Load Balancing and Server Clustering : Adds load balancers to enable horizontal scaling; discusses common scheduling strategies (round‑robin, weighted, IP‑hash, least‑connections, weighted‑least‑connections) and their pros/cons.

4.1 Session Management : Explores sticky sessions, session replication, cookie‑based sessions, and dedicated session servers, outlining benefits and drawbacks such as single‑point failures and bandwidth overhead.

5. Database Read/Write Separation : Uses master‑slave replication to route writes to the master and reads to slaves, requiring an abstraction layer to keep business code unaware of the split.

6. CDN and Reverse Proxy : Employs CDN for geographic latency reduction and reverse proxies for caching static resources, alleviating file‑server pressure.

7. Distributed File System : Introduces a distributed storage solution while ensuring existing online assets remain accessible.

8. Vertical Sharding : Splits databases by functional domains (e.g., Products, Users, Deals) to reduce contention on write‑heavy tables.

9. Horizontal Sharding : Partitions large tables (e.g., User) across multiple databases, discussing shard key selection, data migration, and cross‑shard query challenges.

10. Search Engine Integration : Adds a dedicated search engine (or NoSQL) to handle complex queries, accessed through a unified data‑access module.

11. Final Thoughts : Emphasizes that architecture evolution is driven by real‑world bottlenecks, requiring continuous trade‑off analysis, security considerations, monitoring, and future extensions such as SOA, message queues, and multi‑datacenter deployments.