How Taobao Scaled from LAMP to Cloud: Architecture Evolution & Migration Lessons

Since its founding in 2003, Taobao grew rapidly and launched within three months using a LAMP architecture (PHP, Linux, Apache, MySQL) with about ten application servers and a master‑slave MySQL deployment.

In 2004, to support the booming business, the architecture was upgraded to an Oracle database on an IBM mini‑mainframe with EMC storage, delivering high performance at a higher cost.

The team worried about how to design the system as traffic and transaction volume continued to increase, questioning database choice, caching strategy, and business system construction.

Later, referencing eBay’s design, Taobao built a Java‑based solution using many open‑source Java products: JBoss as the application server, Spring as the IOC container, iBatis for ORM, and a custom ISearch engine for product search, which dumped Oracle data nightly to build searchable indexes on a simple peer‑to‑peer cluster.

From 2006, Taobao created its own CDN to serve static assets such as product images and descriptions, bringing content closer to users and improving browsing speed.

In 2007, with annual transaction volume exceeding 400 billion CNY and over one million daily transactions, the platform introduced the distributed cache TDBM (predecessor of Tair) for hot static data, deployed a self‑developed distributed file system TFS on hundreds of x86 servers to replace commercial NAS, and expanded ISearch to a 48‑node distributed architecture.

In 2008, the monolithic Oracle architecture was split into more than 20 business centers (product, user, transaction, shop, etc.). All access to underlying MySQL databases had to go through remote interfaces provided by these centers, using HSF for remote calls and Notify for asynchronous messaging.

Starting in 2010, Taobao unified its architecture on Alibaba Cloud, leveraging services such as SLB, ECS, RDS, OSS, ONS, and CDN, and achieved dual‑datacenter disaster recovery and modular deployment for higher availability.

The migration from the IOE stack to a cloud platform raised challenges in availability, consistency, performance, and scalability. Best practices included building stateless applications, extensive caching (browser, reverse‑proxy, page, object, read/write splitting), service atomization, database sharding, asynchronous processing, minimizing transaction scope, and selectively relaxing consistency.

Automated monitoring and operations—such as alerting, unified configuration, server, URL, network, module‑call, intelligent analysis, fault management, and capacity planning—were also essential to achieve high scalability, lower cost, better performance, and high availability.

Best Practices for Cloud Migration

For file storage, OSS can replace EMC storage, offering up to 40 PB of distributed capacity and parallel read/write performance; large files benefit from multipart upload.

Application services can be replaced by SLB plus multiple ECS instances, or by Alibaba Cloud middleware such as ACE, ONS, and OpenSearch.

For OLTP workloads, Alibaba Cloud RDS (up to 48 GB memory, 14 000 IOPS, 1 TB SSD) can replace most IBM mainframe + Oracle + EMC configurations.

High‑performance applications may add the Open Cache Service (OCS) to offload queries to a distributed cache, reducing RDS load and improving concurrency, as shown in the diagram.

Read‑heavy scenarios can use multiple RDS instances with read‑write separation, scaling read replicas as needed.

Large tables can be horizontally sharded across several RDS instances to improve performance and capacity.

For OLAP workloads, a solution based on ODPS, OTS, and RDS/ADS can replace the traditional mainframe + Oracle + OLAP + RAC + EMC stack.

Overall, migrating to cloud services using RDS, caching, sharding, and read‑write separation enables a scale‑out replacement of the original IOE architecture, delivering better performance, scalability, and cost efficiency.