Evolution of a Java Web E‑commerce System Architecture: From Single‑Server to Microservices

0 Preface

Using a Java Web example, we build a simple e‑commerce system to illustrate how it can evolve through multiple architectural stages.

1 Single‑Machine Website

All components (Tomcat/Jetty/JBoss, JSP/Servlet, Maven+Spring+Struts+Hibernate or Spring MVC+MyBatis, and a relational DB such as MySQL, SQLServer, Oracle) run on a single machine, forming a basic system.

2 Application Server and Database Separation

To increase load capacity, the web server and database server are split, allowing each to scale independently. Load‑balancing solutions such as Keepalived + ipvsadm are introduced.

3 Application Server Cluster

When a single application server can no longer handle traffic, multiple servers are added. Various load‑balancing methods are discussed:

HTTP redirect (simple but low performance)

DNS round‑robin (no need for a dedicated balancer but slow to react to failures)

Reverse proxy (Apache, Nginx)

IP‑layer load balancing (high performance, bandwidth can become a bottleneck)

Data‑link‑layer load balancing

Cluster Scheduling Algorithms

Round‑robin (rr)

Weighted round‑robin (wrr)

Consistent hash (sh)

Least connections (lc)

Weighted least connections (wlc)

Shortest expected delay (sed)

Never‑queue (nq)

Locality‑based least connections (lblc, lbcr)

Cluster Request Return Modes

Three modes are compared: NAT (balancer forwards request and receives response), DR (direct return, requires IP tunneling), and TUN (direct return without tunneling).

Session Consistency Solutions

Session sticky (IP‑hash)

Session replication

Centralized session storage (database)

Cookie‑based sessions

4 Database Read/Write Splitting

To alleviate database load, master‑slave replication and read/write splitting are introduced, with diagrams of the resulting architecture.

5 Introducing a Search Engine

For fuzzy searches (e.g., product title lookup), a search engine with inverted indexes is added to improve query speed and accuracy, noting the additional maintenance overhead.

6 Caching Layer

Caching mechanisms (application‑level, database‑level, page‑level) are employed to reduce read pressure, using tools such as Guava, Memcached, Redis, and browser storage.

7 Database Vertical and Horizontal Sharding

Vertical sharding separates business domains (users, products, transactions) into different databases; horizontal sharding splits large tables across multiple databases. Advantages, challenges, and solutions (e.g., using MyCat for routing, UUIDs for keys) are discussed.

8 Application Decomposition (Microservices)

The monolithic application is split into smaller services (e.g., user, product, transaction) to avoid code bloat and enable independent scaling.

9 Service‑Oriented Architecture (SOA)

Common functionalities are extracted into shared service centers, improving code reuse and maintenance.

10 Introducing Message Middleware

To support heterogeneous languages and platforms, a message middleware (e.g., Dubbo with Zookeeper) is added for reliable, language‑agnostic communication and load‑balancing transparency.

11 Summary

The presented evolution is illustrative; real‑world architectures must be tailored to specific business needs and continuously refined through analysis and experimentation.