From Monolith to Microservices: Tracing the Evolution of Distributed Architecture

1. Introduction

With societal and technological progress, traditional monolithic architectures have become less mainstream due to high costs and maintenance challenges. Distributed architectures have risen as the dominant solution. Understanding each evolutionary stage helps grasp the benefits of distributed systems.

2. Background

Mature large‑scale websites do not start with perfect performance, high concurrency, or high availability. As user traffic and business features grow, architectures evolve. Different businesses (e.g., e‑commerce, instant messaging, search) prioritize different concerns, leading to distinct architectural paths.

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

3. Stage One: Single‑Application Architecture

In the early internet era, all components run on a single server, emphasizing simplicity and efficiency.

4. Stage Two: Separation of Application and Database Servers

As traffic rises, the web server and database server are split onto separate machines, improving load capacity and disaster recovery.

This separation reduces the risk of site downtime and introduces the need to manage application servers.

5. Stage Three: Application Server Cluster

When a single application server can no longer handle traffic, multiple servers are added to form a cluster, distributing user requests while the database remains a single point.

New challenges arise, such as load balancing and session sharing across servers.

Who forwards user requests to specific application servers?

How to maintain session consistency when users hit different servers?

Solutions include software load balancers (e.g., Nginx, Apache) or hardware load balancers (e.g., F5) and configuring Tomcat for session sharing.

6. Stage Four: Database Read/Write Separation

Increasing database load prompts read/write separation to improve performance while avoiding data inconsistency.

Key issues include master‑slave data synchronization and routing queries to the appropriate data source, often using middleware like Mycat.

7. Stage Five: Introducing Search Engine

To address inefficient fuzzy searches in databases, a search engine is added, greatly speeding up queries but introducing index maintenance and data synchronization challenges.

8. Stage Six: Caching Layer

Hot data is cached using Redis or Memcached to reduce database reads. For rate‑limiting or other scenarios, NoSQL stores like MongoDB can replace 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 splits large tables across multiple databases.

10. Stage Eight: Application Decomposition

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