Designing Scalable E‑Commerce Architecture: From Single‑Server to Distributed Systems

Overview

Large‑site architecture series; this part focuses on an e‑commerce website case, covering functional requirements, non‑functional goals such as high performance, availability, scalability, and extensibility.

Outline

Reason for e‑commerce case

E‑commerce website requirements

Initial website architecture

System capacity estimation

Architecture analysis

Architecture optimization

Summary

1. Reason for the e‑commerce case

Distributed large‑scale sites include portals, social networks, and e‑commerce platforms. E‑commerce combines characteristics of portals (CDN, static content) and social sites (NOSQL, distributed cache), making it a suitable example for analysis.

2. E‑commerce website requirements

Key functional requirements:

Full‑category B2C platform with online purchase, payment, and cash‑on‑delivery.

Online customer service chat.

Product rating and review.

Integration with an existing inventory system.

Support 3‑5 years of growth, targeting 10 million users.

Regular promotional events (Double 11, Double 12, etc.).

Reference features from JD.com or Gome.

Non‑functional requirements highlighted in a requirement‑function matrix include performance, scalability, reliability, security, and extensibility.

3. Initial website architecture

Traditional three‑server setup: one for application, one for database, one for NFS storage. This monolithic approach leads to performance bottlenecks as traffic grows.

Modern architecture adopts clustering for high availability, with load‑balanced application servers and master‑slave database replication.

4. System capacity estimation

Estimation steps: calculate registered users, daily UV, PV, and concurrent users; assume peak traffic 2‑3× normal load; derive required server count.

Example: 2 million daily UV, 30 page views per user → 60 million PV. Assuming 80 % of traffic occurs within 4.8 hours, concurrent users ≈ 2 780, peak ≈ 8 340. Tomcat server handling 300 concurrent requests suggests 10 servers for normal load and 30 for peak.

5. Architecture analysis

Identified issues: excessive server count during peaks, tight coupling of applications, redundant code, session synchronization overhead, and database pressure.

Recommended optimizations: business decomposition, clustered deployment, multi‑level caching, single sign‑on, database clustering (read/write splitting, sharding), service‑oriented design, and message queues.

6. Architecture optimization

6.1 Business decomposition

Separate subsystems: product, shopping, payment, review, customer service, and external interfaces. Core systems (product, shopping, payment) receive higher priority and can be protected during traffic spikes.

6.2 Clustered deployment and load balancing

Deploy each subsystem on multiple nodes, use RPC for inter‑service communication, and place a load balancer in front of application servers and database clusters.

6.3 Multi‑level caching

Use local cache for static dictionaries and a distributed cache (e.g., Redis) as second‑level cache; fallback to database when both caches miss.

6.4 Single sign‑on (distributed session)

Store session data in a distributed cache (Redis) with expiration, enabling cross‑system authentication.

6.5 Database clustering

Adopt master‑slave replication, read/write splitting, and sharding (by product category or time) to handle massive data volumes and improve performance.

6.6 Service‑oriented architecture

Extract common functionalities (e.g., membership) into reusable services.

6.7 Message queue

Use a message broker (e.g., RabbitMQ) to decouple order processing, inventory reduction, and delivery, achieving asynchronous, high‑availability communication.

6.8 Additional techniques

Incorporate CDN, reverse proxy, distributed file system, and big‑data processing as needed.

7. Summary

The case study demonstrates how an e‑commerce platform evolves from a simple three‑server model to a distributed, scalable architecture that satisfies both functional and non‑functional requirements. Specific design choices must be adapted to the actual business scenario.