From Monolith to Microservices: Tracing the Evolution of Distributed Web Architecture

1. Introduction

With societal development and technological progress, traditional mainframe architectures have become less mainstream due to high cost and maintenance difficulty. Distributed architecture has emerged as the dominant model. Understanding each evolutionary stage helps appreciate the benefits of distributed systems.

2. Background

A mature large‑scale website does not start with perfect performance, high concurrency, high availability, or security. These qualities evolve as user traffic and business functions grow, prompting changes in development models and technical architecture. Different business types (e.g., e‑commerce, instant messaging, search) have distinct architectural focuses.

We illustrate the evolution using a simple Java‑Web e‑commerce system, focusing on data volume and traffic growth rather than specific business features.

Assumed system functions:

User module: registration and management.

Product module: display and management.

Transaction module: order creation and payment settlement.

3. Stage One – Single‑Application Architecture

In the early Internet era, all programs and services run on a single server, emphasizing efficiency.

4. Stage Two – Separation of Application and Database Servers

As traffic rises, separating the web server from the database server improves load capacity and fault tolerance.

5. Stage Three – Application Server Cluster

When a single application server can no longer handle traffic, multiple application servers are added and load‑balanced, while the database remains unchanged.

New challenges appear:

Who handles request routing and load balancing?

How to maintain session consistency across servers?

Typical solutions involve software load balancers (e.g., Nginx, Apache) or hardware appliances (e.g., F5) and configuring Tomcat session sharing.

6. Stage Four – Database Read‑Write Separation

Increasing load shifts pressure to the database. Splitting read and write traffic across separate database instances avoids data inconsistency while improving performance.

Key issues:

Data synchronization between master and slave databases (e.g., MySQL replication).

Routing queries to the appropriate data source, often using middleware such as Mycat.

7. Stage Five – Introducing a Search Engine

Search operations are costly for relational databases. Adding a search engine (e.g., Elasticsearch) accelerates queries but introduces index maintenance and data synchronization challenges.

8. Stage Six – Caching Layer

Hot data can be cached with Redis or Memcached to reduce database load. For rate‑limiting or other scenarios, NoSQL stores such as MongoDB may replace traditional relational databases.

9. Stage Seven – Horizontal/Vertical Database Sharding

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

10. Stage Eight – Service Decomposition

Growing business complexity leads to splitting the monolithic application into domain‑specific services (e.g., user, product, transaction). Shared functionality should be abstracted into common services, and inter‑service communication is typically achieved via RPC frameworks such as Dubbo, WebService, Hessian, HTTP, or RMI.