Evolution of Taobao Backend Architecture from Single‑Machine to Cloud‑Native Microservices

1. Overview

Using Taobao as an example, this article describes the evolution of server‑side architecture from a few hundred users to tens of millions of concurrent requests, enumerating the technologies encountered at each stage and summarizing architectural design principles at the end.

2. Basic Concepts

Before discussing architecture, the article introduces fundamental concepts such as distributed systems, high availability, clusters, load balancing, and forward/reverse proxy.

3. Architecture Evolution

Single‑machine Architecture

Initially Tomcat and the database were deployed on the same server; DNS resolved www.taobao.com to a single IP.

Architecture bottleneck: resource contention between Tomcat and the database.

First evolution: Separate Tomcat and database

Tomcat and the database were placed on separate servers, improving performance.

Architecture bottleneck: database read/write becomes the bottleneck.

Second evolution: Introduce local and distributed cache

Local cache (e.g., memcached) and distributed cache (Redis) are added to cache hot items, reducing database load.

Architecture bottleneck: after caching, Tomcat becomes the performance limiter.

Third evolution: Reverse proxy for load balancing

Deploy multiple Tomcat instances and use Nginx or HAProxy as a layer‑7 reverse proxy to distribute requests.

Architecture bottleneck: database becomes the new bottleneck.

Fourth evolution: Database read/write separation

Introduce read replicas using middleware such as Mycat; writes go to a master, reads are served by slaves.

Architecture bottleneck: uneven traffic among business modules leads to contention.

Fifth evolution: Business‑level sharding

Separate databases per business domain to reduce cross‑business contention.

Architecture bottleneck: single write master eventually hits performance limits.

Sixth evolution: Split large tables

Hash‑based or time‑based partitioning creates many small tables, enabling horizontal scaling; mentions MPP databases such as Greenplum, TiDB, PostgreSQL‑XC, HAWQ, etc.

Architecture bottleneck: Nginx becomes the limiting factor.

Seventh evolution: LVS/F5 for multi‑Nginx load balancing

Use layer‑4 load balancers (LVS software or F5 hardware) with keepalived for high availability.

Architecture bottleneck: LVS single‑node limits scalability.

Eighth evolution: DNS round‑robin across data centers

Configure DNS to return multiple IPs, directing users to different data centers for global load balancing.

Architecture bottleneck: data richness and analytics demand exceed database capabilities.

Ninth evolution: Introduce NoSQL and search engines

Adopt HDFS, HBase, Redis, ElasticSearch, Kylin, Druid, and other components for large‑scale storage, key‑value access, full‑text search, and multidimensional analysis.

Architecture bottleneck: increasing component count makes maintenance harder.

Tenth evolution: Split monolithic application into smaller services

Divide code by business modules; use Zookeeper for distributed configuration.

Architecture bottleneck: duplicated common modules across services.

Eleventh evolution: Extract reusable functions into microservices

Common functions (user management, order, payment, authentication) become independent services; governance via Dubbo or Spring Cloud.

Architecture bottleneck: heterogeneous service interfaces increase complexity.

Twelfth evolution: Enterprise Service Bus (ESB)

ESB unifies protocol conversion and reduces coupling, similar to SOA.

Architecture bottleneck: deployment and environment conflicts grow.

Thirteenth evolution: Containerization

Docker and Kubernetes package services as containers, enabling dynamic deployment and scaling.

Architecture bottleneck: still requires on‑premise resources for peak load.

Fourteenth evolution: Cloud platform

Deploy to public cloud, leveraging IaaS, PaaS, and SaaS to obtain elastic resources and reduce operational cost.

4. Architecture Design Summary

Architecture adjustments need not follow a strict linear path; solutions depend on actual bottlenecks.

Design depth should match performance requirements and future growth.

Service‑side architecture differs from big‑data architecture; the latter provides storage and computation capabilities.

Design principles include N+1 redundancy, rollback capability, feature toggles, monitoring, multi‑active data centers, mature technology adoption, horizontal scalability, buying non‑core components, commercial hardware, rapid iteration, and stateless services.