Evolution of 58.com Architecture: From Single‑Server All‑In‑One to Scalable Service‑Oriented System

For many startups it is hard to predict how their website architecture will look when traffic grows tenfold, hundredfold, or thousandfold; building a ten‑million‑concurrent architecture from the start would be prohibitively costly.

Therefore, the evolution of the architecture is examined stage by stage, identifying the problems faced at each level and how solving them drives strategic architectural changes.

In its early days, 58.com handled only about a hundred‑thousand visits per day, with a simple "ALL IN ONE" setup where the site, database, and files all lived on a single machine. Engineers mainly performed CRUD operations, and the technology stack was Windows, IIS, SQL‑Server, and C# because the first two engineers only knew those tools.

If we could start over, we would choose LAMP. LAMP offers rapid, compilation‑free development, powerful open‑source components, and zero licensing cost, making it a better fit for early‑stage products.

When traffic crossed the hundred‑thousand mark, the database became a bottleneck and the single‑machine architecture could no longer handle peak loads. The system moved to a distributed setup with multiple servers, employing static‑dynamic separation and read‑write separation via master‑slave replication.

To alleviate coupling and read‑write latency, the business was vertically split (e.g., homepage vs. posting page) and the database was sharded into smaller units, improving performance and reducing delay.

Additional techniques such as CDN for static assets, MVC pattern for clearer role separation, and load balancing were introduced to further enhance stability and scalability.

Large‑scale phase: migrating the entire Windows stack to Java. As traffic exceeded ten million, performance and cost pressures forced a migration to a Java‑based ecosystem, covering OS, database, and other components.

With rapid growth, many services and sites were added, leading to code duplication and inter‑service dependencies. To improve efficiency, a dedicated service layer was built, handling all business logic, caching, and routing requests through a unified framework.

High availability was ensured using reverse proxy, DNS clustering, LVS, and redundancy at the site, service, and data layers. An internal image storage system was also developed and later open‑sourced.

As the architecture became a "spider web," manual operations could no longer keep up. Automation was introduced across regression testing, monitoring, and operations, while intelligent features such as recommendation, advertising, and search were added.

Future challenges include supporting over a billion daily visits, mobile and wireless demands, real‑time big‑data computation, and scaling the server fleet from a few thousand to tens of thousands.

In summary, different traffic stages require different architectural solutions: early stages focus on development efficiency with ORM/DAO; medium traffic introduces static/dynamic separation, read‑write splitting, CDN, and MVC; large traffic demands vertical splitting, service‑orientation, reverse proxy, and high‑availability mechanisms; ultra‑large traffic calls for centralized configuration, flexible services, message buses, and extensive automation.