How Taobao Scaled from LAMP to Cloud: Architecture Lessons for Enterprises

At its inception, Taobao quickly launched using the popular LAMP stack—PHP, Linux, Apache, and MySQL—deployed on about ten application servers with a master‑slave MySQL setup.

In 2004, driven by business growth, the architecture shifted to an Oracle + IBM mini‑mainframe database with EMC storage, offering superior performance but higher cost.

Facing increasing traffic, Taobao adopted a Java‑based solution inspired by eBay, using JBoss as the application server, Spring for IoC, iBATIS for ORM, and a custom ISearch engine to offload product search from Oracle.

From 2006, Taobao built its own CDN to serve static assets (images, descriptions) closer to users, improving access speed.

By 2007, with daily transactions exceeding 100 million, Taobao introduced the distributed cache TDBM (predecessor of Tair) to cache hot static data in memory, and deployed its own distributed file system TFS on x86 servers to replace commercial NAS, reducing costs and increasing capacity.

In 2008, the monolithic Oracle architecture was decomposed into over 20 business domains (product, user, transaction, shop, etc.) using remote interfaces via HSF and asynchronous messaging with Notify, forming a distributed architecture (see image).

Since 2010, Taobao standardized its infrastructure on Alibaba Cloud, leveraging services such as SLB, ECS, RDS, OSS, ONS, and CDN, achieving high availability through multi‑datacenter disaster recovery and unified management.

The migration presented challenges in availability, consistency, performance, and scalability, which were addressed by stateless application design, extensive caching (browser, reverse‑proxy, page, object, read/write splitting), service atomization, database sharding, asynchronous processing, and automated monitoring and operations.

Best Practices for Cloud Migration

File storage can be replaced by OSS, offering up to 40 PB of distributed storage and multipart upload for large files.

Application services can be built with SLB + multiple ECS instances, or using Alibaba Cloud middleware such as ACE, ONS, and OpenSearch.

For OLTP workloads, RDS (up to 48 GB memory, 14 000 IOPS, 1 TB SSD) can replace IBM mainframes and Oracle, optionally enhanced with OCS caching to reduce database queries.

Read‑heavy scenarios benefit from read/write splitting across multiple RDS instances, while sharding large tables across RDS nodes improves capacity and performance.

OLAP workloads can be migrated to ODPS + OTS + RDS/ADS, replacing the legacy mainframe‑Oracle‑RAC solution.

Overall, a scale‑out approach—combining RDS migration, caching, sharding, and read/write splitting—enables replacement of the original IOE architecture with superior performance, scalability, and cost efficiency.