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

Introduction

The article uses a Java Web example to build a simple e‑commerce system and demonstrates how the system can evolve step by step.

Stage 1 – Single‑Machine Deployment

Initially all components (Tomcat/Jetty, JSP/Servlet, Maven + Spring + Struts + Hibernate or Spring MVC + MyBatis, and a relational database such as MySQL) run on a single machine, forming a basic system.

Stage 2 – Separate Application and Database Servers

To improve load capacity, the web server and database server are split onto different machines, increasing both performance and fault tolerance.

Stage 3 – Application Server Cluster

When a single application server can no longer handle traffic, multiple servers are added. Load balancing solutions such as HTTP redirect, DNS round‑robin, reverse proxy (Nginx/Apache), IP‑layer, and data‑link‑layer balancing are discussed, along with their pros and cons.

Stage 4 – Read‑Write Splitting and Master‑Slave Replication

To handle growing database load, read‑write separation and master‑slave replication are introduced, with diagrams showing the architecture and discussion of synchronization and data source selection challenges.

Stage 5 – Search Engine for Fuzzy Queries

Search engines with inverted indexes are used to replace costly fuzzy SQL LIKE queries, improving query speed and accuracy for product searches.

Stage 6 – Caching

Various caching layers (page, application‑level using Guava or Memcached, and database‑level using Redis) are described, along with their benefits and maintenance overhead.

Stage 7 – Database Sharding (Vertical & Horizontal)

Vertical sharding separates business domains (users, products, transactions) into different databases, while horizontal sharding splits a single table across multiple databases to overcome size and write‑throughput limits. Solutions for distributed transactions, routing, and pagination are provided, often using middleware such as MyCat.

Stage 8 – Microservice Decomposition

The monolithic application is split into microservices (e.g., user, product, transaction services). Shared code is extracted into common service centers to avoid duplication.

Stage 9 – Message Middleware

To enable language‑agnostic communication and transparent load balancing across services, a message middleware (e.g., Dubbo with Zookeeper) is introduced, providing service registration, discovery, and reliable data transfer.

Conclusion

The evolution described is illustrative; real‑world architectures must be tailored to specific business needs and constraints, requiring continuous analysis and adaptation.