Evolution of a Java Web E‑Commerce System: From Single‑Server to Distributed Architecture

Introduction

The article uses a JavaWeb example to illustrate how a simple e‑commerce system can evolve through multiple architectural stages.

Stage 1 – Single‑Machine Deployment

Initially all components (Tomcat/Jetty, JSP/Servlet, Spring‑based frameworks, and a relational database such as MySQL) run on one server, forming a basic functional system.

Stage 2 – Separation of Application Server and Database

To improve load capacity and fault tolerance, the web server and database are moved to separate machines, allowing independent scaling.

Stage 3 – Application Server Cluster

When traffic grows, multiple application servers are added behind a load balancer (e.g., keepalived + ipvsadm). Various load‑balancing methods (HTTP redirect, DNS, reverse proxy, IP‑layer, data‑link‑layer) are discussed.

Stage 4 – Database Read/Write Splitting

The database is split into master and slave nodes to offload read traffic, using MySQL native replication or middleware such as MyCat.

Stage 5 – Adding a Search Engine

To handle expensive fuzzy searches on product titles, a search engine with inverted indexes is introduced, improving query speed at the cost of additional maintenance.

Stage 6 – Caching Layer

Both application‑level (Guava, Memcached, Redis) and page‑level (HTML5 localStorage, cookies) caches are added to reduce database load and improve response time, with consistency handled via consistent hashing.

Stage 7 – Database Sharding

Vertical sharding separates business domains (users, products, transactions) into different databases, while horizontal sharding splits large tables across multiple instances; both approaches are supported by middleware like MyCat.

Stage 8 – Application Splitting and Service‑Oriented Architecture

The monolithic application is divided into smaller services (e.g., user service, product service) and a SOA layer is introduced to share common functionality, improving code reuse and maintainability.

Stage 9 – Introducing Message Middleware

To enable language‑agnostic, reliable communication between distributed components, a message middleware stack (e.g., Dubbo with Zookeeper) is added, providing service registration, discovery, and load‑balanced RPC.

Conclusion

The evolution described is illustrative; real‑world systems must adapt these patterns based on specific business needs and constraints.