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

Good architecture is not designed upfront; it evolves as traffic and business requirements grow.

For many startups it is hard to predict what the architecture will look like after traffic increases tenfold, hundredfold, or thousandfold, and building a ten‑million‑concurrent system from day one is often financially impossible.

The focus, therefore, is on evolving the architecture stage by stage, identifying the problems each traffic level brings, and continuously solving them.

When 58.com first launched, traffic was only around a hundred thousand visits per day, meaning only a few requests per second. The site was tiny, with minimal code, data, and infrastructure, and could be handled by a handful of engineers—there was essentially no architecture.

In this early phase the architecture was an "ALL IN ONE" single‑machine deployment where the web site, database, files, and everything else lived on one server.

Engineers spent most of their time writing CRUD code: the front‑end sent data, the business layer assembled CRUD queries, the database returned results, and the page was rendered back to the browser.

Originally 58.com used a Windows/IIS/SQL‑Server/C# stack, which many modern startups now avoid.

If we could start over, we would choose LAMP. LAMP offers rapid, compiler‑free development with mature, free, open‑source components, allowing a functional forum to be built in two days, making it a better choice for early‑stage startups.

At this stage the main problem was hiring; engineers frequently made CRUD mistakes. Introducing DAO and ORM allowed developers to work with objects instead of raw SQL, greatly improving productivity and reducing errors.

Medium Scale: Traffic Crosses 100k, Database Becomes a Bottleneck

As traffic surged past the hundred‑thousand mark, the site began to experience crashes during peak loads because the database could not keep up, turning it into the primary bottleneck. The infrastructure expanded from a single machine to multiple machines, forming a distributed architecture.

Common techniques such as static/dynamic separation and read‑write splitting were applied. Because most traffic is read‑heavy, master‑slave replication with multiple databases was introduced to scale reads.

The core conflict at this stage was "site coupling + read/write latency". 58.com tackled it by decoupling business modules (e.g., home page, posting page, list page, detail page) and splitting databases into smaller shards, which reduced latency and improved load times.

Additional improvements included using a CDN for static assets, adopting the MVC pattern to separate presentation, controller, and data layers, and employing load‑balancing technologies.

High Traffic: Migrating the Entire Windows Stack to Java

When traffic exceeded ten million requests per day, performance and cost became critical. The original Windows‑based stack could not meet the demands, so a major migration to a Java‑based ecosystem (OS, database, etc.) was undertaken.

Similar migrations have been performed by other large internet companies (e.g., JD, Taobao) as traffic grows.

Rapid hiring led to many engineers writing repetitive code and creating tight inter‑service dependencies, which hurt efficiency.

To improve availability, vertical business splitting continued, a caching layer was added, and a relatively independent service layer was built to handle all business logic centrally.

The service layer first checks the cache; if the data is fresh it returns it directly, otherwise it fetches from the database, updates the cache, and returns the result, thereby centralizing and optimizing business logic.

High availability is ensured through reverse‑proxy, DNS load‑balancing, LVS, and redundancy at the site, service, and data layers. Redundant servers and databases provide failover, though data consistency must be managed.

58.com also built its own image storage system and open‑sourced its site and service frameworks (Argo and Gaea) to reduce development cost.

When the Architecture Becomes a “Spider Web”, Manual Operations Fail

Continued growth in users, data, and concurrency demands rapid product iteration and high automation.

A configuration center was introduced for service discovery and automatic scaling; when a machine is added or removed, the center propagates the change.

Flexible services automatically spin up new instances as traffic rises, and vertical, wireless, and integrated business lines are linked through the configuration center.

Database sharding is applied per business line to handle massive data volumes, with a centralized service layer managing access.

Automation now covers regression testing, deployment, monitoring, and operations.

Intelligent features such as recommendation, ad targeting, and search ranking are driven by the underlying technology.

Future Challenges

With traffic now exceeding one billion requests, 58.com faces challenges in wireless/mobile access, rapid requirement changes, real‑time computation for recommendations, and scaling the server fleet from ~3,000 to ~10,000 machines, which will test operations and maintenance capabilities.

Conclusion

Different traffic stages present distinct problems, and the solutions evolve accordingly: early stages focus on development efficiency with ORM/DAO; medium traffic introduces static/dynamic separation, read/write splitting, master‑slave replication, vertical splitting, CDN, and MVC; high traffic adds service‑orientation, reverse‑proxy, and custom frameworks; ultra‑high traffic requires centralization, flexible services, message buses, and full automation. Future work will continue to push toward real‑time, scalable, and automated systems.