How 58.com Scaled from 10k to Over 1 Billion Visits: Lessons in Evolving Architecture

For many startups, as traffic grows from hundreds of thousands to millions and then to tens of millions or even billions, the website architecture must evolve. This article analyzes the architectural changes required at each stage, based on insights from Shen Jian, executive chair of 58.com’s technical committee.

Good architecture is evolved, not designed

Early-stage startups cannot predict the architecture needed for ten‑fold, hundred‑fold, or thousand‑fold traffic increases, and building a massive‑scale architecture from the start is often unaffordable.

The focus is on identifying the architectural challenges at each traffic stage and continuously solving them, allowing the architecture to evolve.

Initial “All‑in‑One” Phase

When 58.com first launched, traffic was around a hundred thousand visits, meaning only a few requests per second. The architecture was simple: a single machine hosted the site, database, files, etc. Engineers could handle everything manually, so there was essentially no architecture.

The early setup resembled a monolithic system, with all components on one server. Developers mainly performed CRUD operations, handling data from the front end, assembling business logic, querying the database, and returning HTML pages.

Initially 58.com used Windows, IIS, SQL Server, and C#.

If We Could Start Over, We’d Choose LAMP

For early‑stage startups, a LAMP stack is attractive because it requires no compilation, enables rapid deployment, and consists of mature, free, open‑source components. A simple forum can be built in two days, making Windows less appealing for new projects.

At this stage, 58.com’s main issue was hiring; developers made many CRUD errors. Introducing DAO and ORM allowed developers to work with objects instead of raw SQL, greatly improving efficiency and reducing mistakes.

Medium Scale: Crossing the Hundred‑Thousand Threshold – Database Becomes a Bottleneck

As traffic surpassed a hundred thousand requests, the site began to experience crashes during peak loads because the database became a bottleneck, slowing down responses as more users accessed the site.

Common techniques were applied: static and dynamic resource separation, and read/write splitting. Since most traffic is read‑heavy, master‑slave replication was used to distribute read requests across multiple databases, alleviating load.

The site’s architecture was tightly coupled, causing a single failure to affect the entire system. To decouple, 58.com vertically split business functions (e.g., homepage, posting page, list page, detail page) and partitioned large data sets into smaller tables.

Additional improvements included using a CDN for static assets, adopting the MVC pattern to separate concerns, and implementing load balancing.

High Traffic: Migrating from Windows to Java Stack

When traffic exceeded ten million, performance and cost became critical. The original Windows‑based stack could not meet the demands, so 58.com made a decisive shift to a Java‑based ecosystem, covering OS, databases, and middleware.

Rapid growth led to hundreds of servers and many interdependent services. To maintain high availability, 58.com introduced a dedicated service layer, cache mechanisms, reverse proxy (LVS), DNS load balancing, and redundancy for both site and data services.

They also built an internal image storage system and open‑sourced their site and service frameworks (Argo and Gaea) to reduce development costs.

When Architecture Becomes a “Spider Web”, Manual Management Fails

With massive user, data, and concurrency growth, product iteration speed demanded higher automation. The team introduced a configuration center for dynamic service discovery and scaling, and flexible services that automatically provision new instances as traffic rises.

Database access was centralized, and data partitioning was applied per business line to handle ever‑increasing volumes.

Automation extended to regression testing, monitoring, and operations, while intelligent features such as recommendation, advertising, and search were driven by algorithmic enhancements.

Future Challenges

Now exceeding one billion visits, 58.com faces challenges like wireless and mobile demand, rapid feature iteration, real‑time computation, and scaling the server fleet from ~3,000 to 10,000 machines, requiring advanced operations and parallel processing capabilities.

Conclusion

Different traffic stages present distinct problems, and the solutions evolve accordingly. Early on, the focus is on development efficiency with ORM/DAO. As traffic grows, techniques like static/dynamic separation, read/write splitting, master‑slave replication, vertical splitting, CDN, and MVC improve stability. For massive traffic, vertical splitting, service‑oriented architecture, reverse proxy, and custom frameworks ensure high availability. At the hundred‑million‑plus level, centralized configuration, flexible services, message buses, and full automation address the new challenges. Future work will involve mobile, big‑data real‑time processing, and platformization, continuing the endless evolution of system architecture.