Designing High‑Performance, Highly‑Available, Scalable E‑Commerce Architecture

1. Characteristics of Large‑Scale Websites

Massive user base and wide distribution

High traffic and concurrency

Massive data with high availability requirements

Hostile security environment

Frequent feature changes and releases

Gradual growth from small to large

User‑centric design

Free services with paid experiences

2. Architectural Goals

High performance: fast response time, high throughput, stable metrics

High availability: continuous service access

Scalability: add or remove hardware to adjust processing capacity

Security: encrypted communication, secure storage, robust policies

Extensibility: modular addition or removal of functions

Agility: rapid response to changing business needs

3. Architecture Patterns

Layered structure (application, service, data, management, analytics)

Modular division by business or function

Distributed deployment across multiple physical machines

Clustered instances with load balancing

Caching close to the application or user

Asynchronous processing (request‑response‑notification)

Redundancy for availability, security, and performance

Automation of repetitive tasks

Agile handling of requirement changes

4. High‑Performance Architecture

Focus on user‑centric fast page access. Optimize across four layers:

Frontend optimization: reduce HTTP requests, enable compression, use CDN, reverse proxy, browser caching, async JS, minimize cookies.

Application‑layer optimization: employ caching, asynchronous calls, clustering.

Code‑level optimization: multithreading, object/thread pools, efficient data structures, JVM tuning, singleton, cache patterns.

Storage optimization: SSDs, fiber links, read‑write tuning, disk redundancy, distributed storage (HDFS), NoSQL.

5. High‑Availability Architecture

Guarantee continuous service despite failures. Use redundancy and failover at each layer:

Application layer: stateless design, load balancing with session synchronization.

Service layer: load balancing, tiered management, fast failure, async calls, degradation, idempotent design.

Data layer: hot‑standby, synchronous/asynchronous replication, CAP considerations (consistency, availability, partition tolerance).

6. Scalability Architecture

Scale capacity by adding or removing servers without redesigning the core architecture.

Application layer: vertical or horizontal partitioning, load balancing via DNS, HTTP reverse proxy, IP.

Service layer: similar to application layer.

Data layer: sharding, partitioning, NoSQL, consistent hashing.

7. Extensibility Architecture

Enable easy addition or removal of modules:

Modular, component‑based design with high cohesion and low coupling.

Stable interfaces allow internal changes without affecting callers.

Apply design patterns and OOP principles.

Use message queues for decoupled communication.

Service‑oriented architecture for reusable components.

8. Security Architecture

Address known and unknown threats through policies, encryption, and hardening:

Infrastructure security: secure hardware procurement, OS patching, firewalls, anti‑virus, DDoS protection, network segmentation.

Application security: prevent XSS, injection, CSRF, secure file handling; use WAFs like ModSecurity.

Data security: encrypted storage, access control, regular backups, secure transmission (TLS).

9. Agility

Design operations and architecture to adapt quickly to traffic spikes, business growth, and rapid feature delivery.

10. Example Architecture (Seven‑Layer Logical Model)

Layers from bottom to top: client, frontend optimization, application, service, data storage, big‑data storage, big‑data processing.

11. Evolution of Large‑Scale E‑Commerce Architecture

Typical progression:

Single‑server deployment (application, DB, files together).

Separate servers for application, database, and files.

Introduce caching (local and distributed) to serve hot data.

Deploy application clusters behind load balancers (hardware F5 or software LVS/Nginx/HAProxy).

Implement read‑write splitting and sharding for databases.

Use CDN and reverse proxies to reduce latency across regions.

Adopt distributed file systems (GFS, HDFS, TFS) for massive file storage.

Integrate NoSQL (MongoDB, HBase, Redis) and search engines (Lucene, Solr, Elasticsearch) for flexible data queries.

Split monolithic applications into business‑specific services.

Build distributed services using frameworks like Dubbo.

12. Capacity Estimation for a 10‑Million‑User E‑Commerce Site

Assumptions: 2 M daily UV, 30 page views per user → 60 M PV per day. Peak traffic ≈ 3× normal → 180 M PV in 4.8 hours, yielding ~2780 QPS (average) and up to ~8340 QPS at peak. Estimate one Tomcat instance handles ~300 QPS, thus 10 servers for normal load and 30 servers for peak.

13. Architectural Optimization Checklist

Business domain splitting

Application clustering with load balancing

Multi‑level caching (local + distributed)

Distributed session / single sign‑on

Database clustering (read‑write splitting, sharding)

Service‑oriented architecture

Message queues for asynchronous processing

Additional techniques: CDN, reverse proxy, distributed file systems, big‑data processing

14. Detailed Optimizations

14.1 Business Splitting

Separate core systems (product, shopping, payment) from non‑core (reviews, customer service, external integrations) to allow independent scaling and fault isolation.

14.2 Application Cluster Deployment

Deploy each service on multiple nodes, use load balancers for traffic distribution, and ensure at least two instances per service for redundancy.

14.3 Multi‑Level Caching

Use local in‑memory cache for immutable dictionaries and a distributed cache (e.g., Redis) for hot data; fallback to the database when both caches miss. Typical cache ratio 1:4.

14.4 Distributed Session / Single Sign‑On

Store session data in a distributed cache (Redis) with expiration (e.g., 15 minutes) to enable seamless login across services.

14.5 Database Cluster (Read‑Write Splitting & Sharding)

Apply master‑slave replication for read‑write separation; shard large tables horizontally or vertically based on business domains. Middleware examples: Cobar, TDDL, Atlas, MyCat.

14.6 Service‑Oriented Architecture

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

14.7 Message Queues

Use MQ (RabbitMQ, ActiveMQ, etc.) to decouple order processing, inventory reduction, and delivery workflows, achieving asynchronous, high‑throughput handling.

14.8 Other Techniques

Include CDN, reverse proxy, distributed file systems, and big‑data analytics as needed.