Evolution of Taobao Backend Architecture: From Single‑Server to Cloud‑Native Scalability

The article begins by defining basic concepts needed for understanding architecture design, including distributed systems, high availability, clusters, load balancing, and the differences between forward and reverse proxies.

Basic Concepts

Distributed: multiple modules deployed on different servers. High availability: other nodes take over when a node fails. Cluster: a group of servers providing a unified service, often with automatic failover.

Evolution Stages

Stage 1 – Single Machine: Tomcat and the database run on the same server; limited scalability as user traffic grows.

Stage 2 – Separate Tomcat and Database: Deploy Tomcat and the database on separate servers, improving resource isolation but database read/write becomes a bottleneck.

Stage 3 – Local and Distributed Caching: Introduce local cache (e.g., memcached) and distributed cache (e.g., Redis) to offload read traffic from the database.

Stage 4 – Reverse Proxy Load Balancing: Deploy multiple Tomcat instances behind Nginx or HAProxy, distributing requests evenly and increasing concurrent capacity.

Stage 5 – Database Read/Write Separation: Use middleware such as Mycat to split read and write workloads, adding read replicas to alleviate database pressure.

Stage 6 – Database Sharding by Business: Separate data per business into different databases, reducing contention but requiring cross‑database aggregation solutions.

Stage 7 – Table Splitting (Horizontal Partitioning): Split large tables into smaller ones (e.g., by hash or time) and use Mycat for routing, achieving distributed database performance.

Stage 8 – LVS/F5 Layer‑4 Load Balancing: Place LVS or hardware F5 in front of multiple Nginx instances to handle hundreds of thousands of concurrent connections.

Stage 9 – DNS Round‑Robin Across Data Centers: Use DNS to map a domain to multiple IPs, balancing traffic across geographically distributed data centers.

Stage 10 – NoSQL and Search Engines: Introduce technologies such as HBase, Redis, Elasticsearch, TiDB, Greenplum, etc., to handle massive data, full‑text search, and analytical workloads.

Stage 11 – Micro‑services Extraction: Pull common functionalities (user management, order, payment, authentication) into independent services using frameworks like Dubbo or Spring Cloud.

Stage 12 – Enterprise Service Bus (ESB): Use an ESB to unify protocol conversion and reduce coupling between services, resembling SOA architecture.

Stage 13 – Containerization: Package services as Docker images and orchestrate them with Kubernetes for dynamic scaling and isolation.

Stage 14 – Cloud Platform Adoption: Deploy the whole system on public cloud (IaaS, PaaS, SaaS), leveraging elastic resources, managed services, and multi‑region deployment.

Design Experience Summary

The article concludes with practical advice: design for no single point of failure, support rollback, enable feature toggles, embed monitoring, consider multi‑active data centers, adopt mature technologies, isolate resources, ensure horizontal scalability, buy non‑core components, use commercial hardware, iterate quickly, and keep services stateless.

Q&A

1) Architecture evolution does not have to follow a strict linear path; multiple bottlenecks may be addressed simultaneously.

2) The depth of design should meet current performance goals while leaving room for future expansion.

3) Backend architecture focuses on application organization, whereas big‑data architecture provides the underlying storage and processing capabilities.

4) A set of architectural principles is listed, covering N+1 design, rollback, feature disabling, monitoring, multi‑active data centers, mature technology adoption, resource isolation, horizontal scalability, buying non‑core solutions, using commercial hardware, rapid iteration, and stateless design.