How Taobao’s Backend Architecture Evolved Over a Decade

Overview

The article uses an e‑commerce site as a concrete example to illustrate how a backend system evolves from a few hundred users to millions of concurrent requests. Each evolutionary stage is described with the associated technologies, bottlenecks, and trade‑offs.

Basic Concepts

Distributed : Modules run on different servers (e.g., Tomcat and the database on separate machines).

High Availability : The system continues to serve requests when some nodes fail.

Cluster : A group of servers providing the same service with automatic failover.

Load Balancing : Requests are evenly distributed across nodes.

Forward and Reverse Proxy : Forward proxy lets internal services access external networks; reverse proxy forwards external requests to internal servers.

Architecture Evolution

1. Single‑Machine Architecture

Tomcat and the database are deployed on the same server. DNS resolves the domain to a single IP, and all traffic is handled by that Tomcat instance.

2. Separate Tomcat and Database

Tomcat and the database are placed on independent servers, eliminating resource contention and improving the performance of each component.

3. Add Local and Distributed Caching

Local cache (e.g., memcached) is added inside Tomcat, and an external distributed cache (e.g., Redis) stores hot product data or HTML pages. Most read/write requests are intercepted by the cache, greatly reducing database load. The step introduces issues such as cache consistency, cache penetration, cache avalanche, and hot‑spot invalidation.

4. Reverse Proxy Load Balancing

Multiple Tomcat instances are placed behind a reverse‑proxy (e.g., Nginx or HAProxy). Assuming each Tomcat supports 100 concurrent connections and Nginx can handle 50 000, the system can theoretically serve 50 000 concurrent requests. This step raises considerations for session sharing and file upload/download.

5. Database Read‑Write Separation

Using middleware such as Mycat, the database is split into a write master and multiple read replicas. Writes go to the master; reads are distributed among replicas. Data synchronization and consistency become focal points.

6. Business‑Based Database Sharding

Data for different business domains are stored in separate databases, reducing cross‑business contention. Cross‑database joins are no longer possible without additional solutions.

7. Split Large Tables into Small Tables

Tables are partitioned by hash (e.g., product ID) or by time (e.g., hourly tables). This enables horizontal scaling of the database but increases DBA workload. The article mentions MPP databases such as Greenplum, TiDB, PostgreSQL‑XC and commercial options for large‑scale parallel processing.

8. Layer‑4 Load Balancing with LVS or F5

When Nginx becomes the bottleneck, a layer‑4 balancer (software LVS or hardware F5) distributes traffic among multiple Nginx instances. High availability is achieved with keepalived providing a virtual IP that can fail over between LVS nodes.

9. DNS Round‑Robin Across Data Centers

DNS is configured with multiple IPs, each pointing to a different data‑center’s virtual IP. Clients are directed to different data centers via round‑robin or other policies, enabling geographic scaling.

10. Introduce NoSQL and Search Engines

When relational databases cannot handle massive data or complex queries, specialized components are added: HDFS for file storage, HBase/Redis for key‑value, ElasticSearch for full‑text search, Kylin/Druid for multidimensional analysis, etc. The trade‑off is increased system complexity and the need for data synchronization.

11. Split Monolithic Application into Small Applications

Code is divided by business module, each deployed independently. Shared configuration is managed via a distributed configuration center such as Zookeeper.

12. Extract Reusable Functions into Microservices

Common functionalities (user management, order, payment, authentication) are extracted into independent services accessed via HTTP, TCP, or RPC. Frameworks like Dubbo or Spring Cloud provide service governance, rate limiting, circuit breaking, and degradation.

13. Enterprise Service Bus (ESB)

All services communicate through an ESB that performs protocol conversion, reducing coupling. This resembles SOA; the article notes that microservices emphasize independent deployment, while SOA emphasizes unified interfaces.

14. Containerization

Docker packages services into images, and Kubernetes ( K8s) orchestrates their deployment, scaling, and lifecycle. Containers allow rapid provisioning for traffic spikes (e.g., during a promotion) and clean teardown afterward.

15. Cloud Platform Hosting

The system migrates to a public cloud, leveraging IaaS, PaaS, and SaaS layers. Resources (CPU, memory, network) are requested on demand, enabling pay‑as‑you‑go scaling and reducing operational cost.

Architecture Design Summary

The evolution order is not mandatory; real‑world bottlenecks dictate the next step.

Design depth should meet current performance goals while leaving room for future expansion.

Service‑side architecture differs from big‑data architecture, which focuses on data ingestion, storage, and analysis.

Design Principles

N+1 design – no single point of failure.

Rollback capability – ensure forward compatibility and version rollback.

Feature toggle – ability to disable functions quickly during incidents.

Monitoring – embed observability from the design phase.

Multi‑active data centers – achieve high availability across locations.

Use mature technologies – avoid untested open‑source components for critical paths.

Resource isolation – prevent one business from monopolizing resources.

Horizontal scalability – design for scaling out to avoid bottlenecks.

Buy non‑core solutions – consider commercial products for non‑core functionalities.

Commercial hardware – reduces hardware failure probability.

Rapid iteration – develop small features quickly, validate, and reduce delivery risk.

Stateless design – service interfaces should not rely on previous request state.