Evolution Stages of Internet Distributed Architecture: From Single‑Server to Service‑Oriented Design

1. Introduction With the development of society and internet technology, traditional mainframe‑style server architectures have become less mainstream due to high cost and maintenance difficulty, giving way to the currently popular distributed internet architecture.

2. Related Article For readers who have mastered the basics, a recommended follow‑up article is "Tencent Senior Architect Summary: Understanding All Aspects of Large‑Scale Distributed System Design" (http://www.52im.net/thread-1811-1-1.html).

3. Technical Background A mature large‑scale website does not start perfect; it evolves as user volume and business functions grow. Different business types (e.g., e‑commerce, instant messaging, search) have distinct architectural focuses. To illustrate the evolution, a simple Java web e‑commerce system is used as a case study, focusing on data volume, traffic growth, and structural changes rather than specific business features.

Key functional modules assumed:

User module: registration and management

Product module: display and management

Transaction module: order creation and payment settlement

4. Stage One – Single‑Application Architecture

In the early internet era, all programs and services run on a single machine, emphasizing efficiency and rapid deployment.

5. Stage Two – Separation of Application and Database Servers

When traffic increases, the web server and database server are split onto separate machines, improving load capacity and fault tolerance.

6. Stage Three – Application Server Cluster

As traffic continues to rise, multiple application servers are added to form a cluster, requiring load balancing and session sharing solutions (e.g., Nginx/Apache for soft load balancing, Tomcat session replication).

7. Stage Four – Database Read/Write Separation

To alleviate database load, read and write operations are split across master and slave instances, often using MySQL built‑in replication and middleware such as MyCat for routing.

8. Stage Five – Introducing a Search Engine

For fuzzy and high‑throughput queries (e.g., product search), a dedicated search engine (such as Elasticsearch) is added, bringing index maintenance and data synchronization challenges.

9. Stage Six – Caching Layer

Hot data is cached using Redis or Memcached to reduce database reads; for rate‑limiting scenarios, NoSQL stores like MongoDB may be employed.

10. Stage Seven – Database Sharding (Vertical & Horizontal)

When a single database becomes a bottleneck, data is split: vertical sharding separates different business domains into separate databases, while horizontal sharding distributes rows of the same table across multiple databases.

11. Stage Eight – Application Decomposition into Services

Business growth leads to splitting the monolith into domain‑specific sub‑systems (user, product, transaction). Shared functionality is abstracted into services, and inter‑service communication is handled via RPC frameworks such as Dubbo, WebService, Hessian, HTTP, or RMI.

12. Conclusion By walking through an e‑commerce example, the article demonstrates how increasing traffic and business complexity drive successive architectural redesigns—from single‑server setups to micro‑service ecosystems—emphasizing steady, incremental evolution rather than abrupt changes.