Designing a Scalable E‑Commerce Architecture: From Simple Setup to Distributed Systems

Large‑scale website architecture is presented as a series of documents, and this installment focuses on an e‑commerce site case study, covering requirements, an initial architecture, capacity estimation, and optimization toward a reference distributed design.

Outline

Reason for choosing the e‑commerce case

E‑commerce site requirements

Initial site architecture

System capacity estimation

Architecture analysis

Architecture optimization

Summary

1. Why Choose an E‑Commerce Case

Distributed large‑scale sites fall into three categories: portals (e.g., NetEase, Sina), social networks (e.g., campus sites, Kaixin), and e‑commerce platforms (e.g., Alibaba, JD, Guomei, Autohome). Portals rely on CDN and staticization, social networks use NoSQL and distributed caches, while e‑commerce combines both, making it an ideal example.

2. E‑Commerce Site Requirements

Customer requirements:

Build a full‑category B2C e‑commerce site with online purchase, online payment, and cash‑on‑delivery.

Enable real‑time communication with customer service during purchase.

Allow users to rate and review products after receipt.

Integrate with an existing mature ERP/inventory system.

Support 3‑5 years of business growth.

Target 10 million users within 3‑5 years.

Host major promotional events such as Double‑11, Double‑12, and Men's Day.

Reference features from JD.com or Guomei Online.

To capture both functional and non‑functional aspects, a requirement‑function matrix is used. Key non‑functional goals include high performance, high availability, scalability, flexible image storage, secure payment processing, and reliable real‑time communication.

Requirement matrix (functional / non‑functional):

Full‑category e‑commerce site – Category management, product management – Flexible multi‑category handling, fast page load, massive image storage.

Online purchase – Member management, shopping cart, checkout – Good shopping experience (usability, performance).

Online or cash‑on‑delivery payment – Multiple payment methods – Secure payment, data encryption, flexible payment‑gateway switching.

Online customer service – Chat function – Reliability for instant messaging.

Product rating – Comment system – (no specific non‑functional item listed).

ERP integration – Interface with inventory system – Constraint: data consistency and robustness.

3‑5‑year growth support – – Constraint: scalability and extensibility.

10 million users – – Constraint: scalability.

Promotional events – Activity management, flash sales – Traffic spikes (scalability) and real‑time performance.

Reference to JD/Guomei – – Reference condition.

3. Initial Site Architecture

Early‑stage sites often start with three servers: one for the application, one for the database, and one for NFS file storage.

Example of a small portal with 100 k+ members and many images suffered severe performance problems using this single‑server model.

Simple architecture illustration:

Modern large‑scale sites adopt a clustered approach for high availability, typically combining load‑balanced application servers with a primary‑secondary database setup.

Key points:

Clustered application servers provide redundancy and high availability (load balancer can be co‑located).

Database master‑slave replication ensures data backup and high availability.

4. System Capacity Estimation

Estimation steps:

Determine registered user count, daily UV, daily PV, and concurrent users.

Estimate peak load as 2‑3 times the normal load.

Calculate required storage and compute resources based on concurrency and transaction volume.

Given the target of 10 million registered users in 3‑5 years, the following calculations are shown (using the 80/20 rule):

Daily UV ≈ 2 million; each user generates about 30 page views → PV ≈ 60 million per day.

Peak window (≈ 4.8 hours) accounts for 80 % of daily PV → 48 million peak PV.

Peak per‑minute visits: 48 million ÷ 288 minutes ≈ 166 k.

Peak per‑second visits: 166 k ÷ 60 ≈ 2.78 k (≈ 2 800). Assuming a three‑fold surge during flash‑sale events, peak concurrency can reach ≈ 8 300 requests per second.

Server sizing (Tomcat example):

One web server handles ~300 concurrent requests per second → ~10 servers for normal load.

During peak, ~30 servers are needed.

CPU utilization should stay around 70 % under normal conditions and not exceed 90 % at peak, ensuring stable performance without waste of resources. Memory, I/O, network bandwidth follow similar sizing principles.

These figures are illustrative; actual requirements depend on hardware specs, business logic complexity, and other factors.