From Single‑Server to Scalable E‑Commerce: A Step‑by‑Step Java Web Architecture Guide

Introduction

Using a Java web example, we build a simple e‑commerce system and explore how it can evolve step by step.

System Functions

User module: registration and management

Product module: display and management

Transaction module: creation and management

Stage 1 – Single‑Machine Website

Initially all programs run on a single host using a container such as Tomcat or Jetty, JSP/Servlet technology or frameworks like Maven+Spring+Struts+Hibernate or Maven+Spring+SpringMVC+MyBatis, and a database (MySQL, SQLServer, Oracle) accessed via JDBC.

The system runs on one machine as a small application.

Stage 2 – Separate Application Server and Database

As traffic grows, we separate the web server from the database to improve load capacity and fault tolerance.

Stage 3 – Application Server Cluster

When a single application server can no longer handle traffic, we add more servers and use a load‑balancer (e.g., keepalived with ipvsadm) to distribute requests.

Typical problems at this point:

Who forwards user requests to specific application servers?

Which forwarding algorithm to use?

How do application servers return responses?

How to maintain session consistency when users hit different servers?

Solutions include various load‑balancing methods (HTTP redirect, DNS‑based, reverse proxy, IP‑layer, data‑link‑layer) and clustering algorithms (RR, WRR, SH, DH, LC, WLC, SED, NQ, LBLC, LBLCR).

Stage 4 – Database Read/Write Separation

To handle increasing database load, we adopt read/write separation, using a master‑slave MySQL setup or middleware such as Mycat.

New issues arise: master‑slave data synchronization and application data source selection.

Stage 5 – Search Engine for Read Load

Search engines (inverted index) can accelerate fuzzy queries that are costly with SQL LIKE, improving query speed but adding maintenance overhead.

Stage 6 – Caching to Relieve Database Read Pressure

Application‑level caches (Guava, Memcached, Redis) and page caches (HTML5 localStorage, cookies) reduce database load and improve response time, though they require cache server maintenance and increase code complexity.

Stage 7 – Database Vertical and Horizontal Sharding

Vertical sharding separates different business data (users, products, transactions) into distinct databases; horizontal sharding splits a single table across multiple databases to handle large data volume.

Stage 8 – Application Splitting and Service‑Oriented Architecture

We split the monolithic application into smaller services (e.g., user‑product, user‑transaction) and adopt SOA to avoid code duplication and improve maintainability.

Stage 9 – Introducing Message Middleware

To support heterogeneous modules and platforms, we integrate language‑agnostic message middleware (e.g., Dubbo with Zookeeper) for reliable data transmission, load balancing, and monitoring.

Conclusion

The evolution described is illustrative; real‑world architectures depend on specific business needs and constraints, requiring careful analysis and continuous experimentation.