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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaMicroservicesCachingweb architecture
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

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.