From Single-Server to Scalable E‑Commerce: A Step‑by‑Step Backend Evolution Guide

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

Phase 1 – Single‑Machine Website

Initially all components (Tomcat/Jetty, JSP/Servlet, Maven+Spring+Hibernate/MyBatis, MySQL/SQLServer/Oracle via JDBC) run on one machine, forming a small system.

Phase 2 – Separate Application Server and Database

When traffic grows, the application server and database are split onto different machines to improve load capacity and fault tolerance.

Phase 3 – Application Server Cluster

With further traffic increase, multiple application servers are added and requests are distributed among them. Keepalived combined with ipvsadm provides load balancing.

Four problems appear:

How to forward 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:

1. Load‑balancing methods (five common approaches):

HTTP redirect – simple but performance‑poor.

DNS resolution – offloads to DNS but lacks real‑time failure handling.

Reverse proxy (Apache/Nginx) – easy deployment, possible bottleneck.

IP‑layer load balancing – better performance, bandwidth can become bottleneck.

Data‑link layer load balancing – modifies MAC address, avoids returning through the balancer.

2. Scheduling algorithms (ten typical ones): rr, wrr, sh, dh, lc, wlc, sed, nq, lblc, lblcr – each with its own strengths and weaknesses.

3. Cluster mode solutions (NAT, DR, TUN) for request forwarding.

4. Session handling strategies (four common methods): Session sticky (IP‑hash), session replication, centralized session storage (database), cookie‑based session.

Phase 4 – Database Read/Write Splitting

To relieve database load, master‑slave replication or middleware such as MyCat is used to separate read and write traffic.

Phase 5 – Introducing a Search Engine

For fuzzy queries like product title search, an inverted‑index search engine dramatically speeds up queries, though it adds index‑building and cluster maintenance overhead.

Phase 6 – Caching Layer

Application‑level caches (Guava, Memcached) and database‑level caches (Redis) reduce repeated reads of hot data. Page caching via HTML5 localStorage or cookies further improves response speed, at the cost of cache server maintenance and added complexity.

Phase 7 – Database Sharding

Vertical sharding separates different business tables (users, products, orders) into distinct databases, reducing single‑DB pressure but requiring cross‑DB transaction handling.

Horizontal sharding splits a single table across multiple databases to handle massive data volume; challenges include routing, primary‑key generation, and pagination.

Phase 8 – Application Splitting and Service‑Oriented Architecture

Large applications are divided into smaller services (e.g., user‑service, product‑service, order‑service). Common code is extracted into shared services, forming an SOA architecture.

Phase 9 – Introducing Message Middleware

To enable language‑agnostic, reliable communication between distributed modules, middleware such as Dubbo with Zookeeper for service registration and discovery is adopted.

Conclusion

The evolution described is illustrative; real‑world systems must analyze their own business needs and constraints to design appropriate architectures.