Evolution of Taobao Backend Architecture: From Single‑Machine to Cloud‑Native Scale

In this tutorial a senior architect explains how the backend of an e‑commerce platform (using Taobao as an example) evolves to handle traffic ranging from a few hundred concurrent users to tens of millions.

Basic Concepts

Distributed system : multiple modules deployed on different servers (e.g., Tomcat and database on separate machines).

High availability : the ability of remaining nodes to take over when some fail.

Cluster : a group of servers providing the same service, often with load‑balancing and fail‑over.

Load balancing : evenly distributing requests across nodes.

Forward and reverse proxy : forward proxy accesses external networks on behalf of internal services; reverse proxy forwards external requests to internal servers.

Evolution Stages

1. Single‑Machine Architecture

Tomcat and the database run on the same server; suitable for low traffic.

2. Separate Tomcat and Database

Tomcat and the database are deployed on different machines, eliminating resource contention.

3. Introduce Local and Distributed Caching

Local cache (e.g., Memcached) and distributed cache (Redis) store hot data, dramatically reducing database load. Issues such as cache consistency, penetration, and avalanche are discussed.

4. Add Reverse Proxy for Load Balancing

Multiple Tomcat instances are placed behind Nginx (or HAProxy) to spread traffic. Theoretical capacity grows to 50,000 concurrent requests, but the database becomes the new bottleneck.

5. Database Read/Write Separation

Read replicas are added (using middleware like Mycat) to offload read traffic; writes go to a primary node and are synchronized to replicas.

6. Sharding by Business

Data is split into multiple databases per business domain, reducing contention but requiring cross‑database analytics.

7. Table Splitting (Horizontal Partitioning)

Large tables are divided into smaller ones (e.g., by hash of product ID or hourly tables), enabling horizontal scaling of the database layer.

8. Multi‑Data‑Center Load Balancing via DNS

DNS round‑robin directs users to different data‑center IPs, achieving site‑wide load distribution.

9. Add NoSQL and Search Engines

For massive data and complex queries, technologies such as HBase, Elasticsearch, and Hadoop are introduced.

10. Split Monolith into Small Applications

Business modules become independent services, each with its own codebase; shared configuration is handled by Zookeeper.

11. Extract Common Functions as Micro‑services

Functions like user management, order processing, and authentication become independent services using Dubbo or Spring Cloud, with governance features (rate limiting, circuit breaking, etc.).

12. Introduce Enterprise Service Bus (ESB)

ESB unifies protocol conversion and decouples services, forming an SOA‑style architecture.

13. Containerization

Docker images are managed by Kubernetes, providing isolated runtime environments and rapid scaling for promotional events.

14. Move to Cloud Platforms

Adopt IaaS/PaaS/SaaS models to provision resources on demand, reducing operational cost and enabling elastic scaling.

Design Principles

N+1 redundancy to avoid single points of failure.

Rollback capability for safe upgrades.

Feature toggles for quick disabling of problematic components.

Comprehensive monitoring from the design phase.

Multi‑active data‑center design for ultra‑high availability.

Prefer mature, commercially supported technologies.

Resource isolation to prevent one business from monopolizing resources.

Horizontal scalability as a core requirement.

Buy non‑core components when development cost is high.

Stateless service design.

The article concludes with a summary of common architectural bottlenecks and a reminder that deeper issues such as cross‑data‑center synchronization and distributed transactions deserve separate discussion.