Backend Development 17 min read

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

This article outlines the step‑by‑step evolution of a Java web e‑commerce platform, covering initial single‑machine deployment, server‑database separation, application clustering, load‑balancing algorithms, session handling, read‑write splitting, caching, database sharding, microservice decomposition, and the introduction of messaging middleware to achieve a scalable, resilient architecture.

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

We use a Java Web example to build a simple e‑commerce system and demonstrate how it can evolve through multiple stages.

Stage 1 – Single‑machine deployment : All components (Tomcat/Jetty, JSP/Servlet, Spring, MyBatis, MySQL, etc.) run on one server, forming a minimal system.

Stage 2 – Separate application and database servers : To handle increasing traffic, the web server and database server are split, improving load capacity and fault tolerance.

Stage 3 – Application server clustering : 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 introduced.

Stage 4 – Database read/write separation : Master‑slave replication or middleware (e.g., MyCat) is used to separate read and write traffic, addressing database load.

Stage 5 – Search engine for fuzzy queries : To improve product search, an inverted‑index search engine is added, reducing the cost of LIKE queries.

Stage 6 – Caching layer : Application‑level (Guava, Memcached) and database‑level (Redis) caches are introduced, along with page caching (localStorage, static pages) to relieve database pressure.

Stage 7 – Database vertical and horizontal sharding : Vertical sharding separates business domains (users, products, orders) into different databases; horizontal sharding splits large tables across multiple databases, with middleware handling routing, primary‑key generation, and pagination.

Stage 8 – Microservice decomposition : The monolithic application is split into smaller services (e.g., user‑service, product‑service, order‑service) to avoid code bloat and improve maintainability.

Stage 9 – Messaging middleware : Introducing a language‑agnostic message bus (e.g., Dubbo with Zookeeper) enables reliable inter‑service communication, load‑balancing transparency, and operational monitoring.

The final architecture combines load balancers, clustered application servers, read/write‑separated databases, search engines, caching clusters, sharded databases, microservices, and a messaging layer, providing a scalable and resilient solution for large‑scale web applications.

JavaMicroservicesscalabilityLoad BalancingCachingWeb Architecturedatabase sharding
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.