Taobao’s Journey from LAMP to Cloud: Architecture Evolution & Migration Secrets

Since its founding in 2003, Taobao grew at roughly 100% per year. To launch quickly, it adopted the popular LAMP stack—PHP, Linux, Apache, MySQL—and went live in under three months with about ten application servers and a master‑slave MySQL deployment.

In 2004, driven by business growth, Taobao replaced LAMP with an Oracle + IBM mini‑mainframe database architecture and EMC storage, achieving excellent performance but incurring high costs, while the system began to feel the pressure of increasing traffic.

Facing questions about how to design the system as traffic and transaction volume surged, Taobao later referenced eBay’s internet architecture and built a Java‑based solution using many open‑source components.

Key choices included JBoss as the application server, Spring as the IOC container, iBatis for ORM, and a custom ISearch engine for product search, which offloaded search work from Oracle by nightly dumping data and building indexes on a simple server cluster.

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

By 2007, with daily transactions exceeding 100 million, Taobao introduced the distributed cache TDBM (predecessor of Tair) to store hot static data in memory, and deployed its own distributed file system TFS on hundreds of x86 servers, replacing commercial NAS for storing files, images, and transaction snapshots. ISearch was also re‑architected for horizontal scaling across 48 nodes.

In early 2008, to overcome Oracle’s centralized bottlenecks, the system was split into more than 20 business‑center services (product, user, transaction, shop, etc.). Access to underlying MySQL was prohibited; services communicated via HSF remote calls and Notify asynchronous messaging.

Starting in 2010, Taobao unified its architecture on Alibaba Cloud, leveraging SLB, ECS, RDS, OSS, ONS, CDN and the platform’s high‑availability features to achieve dual‑data‑center disaster recovery and modular deployment.

Migration Architecture Best Practices

Key challenges when moving from an IOE (IBM + Oracle + EMC) stack to a cloud platform included ensuring availability on PC‑server clusters, maintaining data consistency (RAC vs. RDS for MySQL), achieving comparable I/O performance, and designing scalable service decomposition, sharding, and data partitioning.

Best‑practice strategies involve stateless applications, extensive caching (browser, reverse‑proxy, page, object, read/write splitting), service atomization, database sharding, asynchronous processing, minimizing transaction scope, and, when necessary, relaxing consistency guarantees. Automated monitoring and operations—alerting, unified configuration, server, URL, network, inter‑module, intelligent analysis, fault management, and capacity planning—are essential for high scalability, lower cost, and superior performance.

For file storage, replace EMC with OSS, which supports up to 40 PB of distributed storage and multipart upload for large files.

Application services can be migrated using SLB plus multiple ECS instances to replace IBM mini‑mainframes, or by adopting Alibaba Cloud middleware such as ACE, ONS, and OpenSearch.

OLTP workloads can run on Alibaba Cloud RDS (up to 48 GB memory, 14 000 IOPS, 1 TB SSD). To boost performance, introduce Open Cache Service (OCS) for caching frequent queries, implement read/write splitting across multiple RDS instances, and horizontally shard large tables across several RDS nodes.

For OLAP scenarios, use a combination of ODPS, OTS, and RDS/ADS to replace the traditional Oracle + RAC + EMC solution.

Overall, migrating to RDS, adding caching layers, sharding databases, and employing read/write separation enable a scale‑out replacement of the original IOE architecture, delivering better performance and extensibility.