Designing High‑Performance, Highly‑Available Large‑Scale Web Architectures

1. Characteristics of Large‑Scale Websites

Massive user base and wide geographic distribution

High traffic and extreme concurrency

Huge data volume with high availability requirements

Harsh security environment, prone to network attacks

Rich functionality, rapid changes, frequent releases

Gradual growth from small to large

User‑centric design

Free services with paid experiences

2. Architecture Goals

High performance – fast response times and high throughput

High availability – services remain accessible at all times

Scalability – ability to add or remove hardware to adjust capacity

Security – encrypted transmission, secure storage, robust access controls

Extensibility – easy addition or removal of modules and features

Agility – rapid response to changing business needs

3. Common Architecture Patterns

Layered: application, service, data, management, analytics layers

Segmentation: split by business/module/function (e.g., homepage, user center)

Distributed deployment across multiple physical machines

Cluster: multiple instances of a component behind a load balancer

Cache: local or distributed caches close to the application or user

Asynchronous processing: request‑response‑notification model

Redundancy: replicas for higher availability, security, and performance

Security: known‑issue solutions and mechanisms for unknown threats

Automation: replace manual tasks with tools and scripts

Agility: embrace change and respond quickly

4. High‑Performance Architecture

Focus on user‑centric fast page access. Key parameters include short response time, high concurrent handling, high throughput, and stable performance.

Frontend optimization – reduce HTTP requests, enable compression, use CDN, leverage browser cache

Application‑layer optimization – caching, asynchronous calls, clustering

Code‑level optimization – multithreading, resource reuse (object/thread pools), efficient data structures, JVM tuning, singleton patterns, in‑process caches

Storage optimization – SSDs, fiber links, read/write tuning, disk redundancy, distributed storage (HDFS), NoSQL databases

5. High‑Availability Architecture

Large sites must remain reachable despite failures; redundancy and failover are essential.

Application layer – stateless design, load balancing (session synchronization needed for stateful services)

Service layer – load balancing, hierarchical management, fast failure (timeouts), async calls, service degradation, idempotent design

Data layer – master‑slave replication (cold, hot, warm), failover, CAP theorem considerations (consistency, availability, partition tolerance)

6. Scalability Architecture

Scale capacity by adding or removing servers without redesign.

Application layer – vertical or horizontal partitioning, load balancing via DNS, HTTP reverse proxy, IP, or layer‑2 methods

Service layer – similar partitioning as application layer

Data layer – sharding (horizontal) and database splitting (vertical) using hash or consistent‑hash algorithms

7. Extensibility Architecture

Modular & component‑based design – high cohesion, low coupling, reusable

Stable interfaces – keep APIs unchanged while internal implementation evolves

Design patterns – apply OOP principles and patterns for clean code

Message queues – decouple modules via asynchronous messaging

Distributed services – expose common functionalities (e.g., user, order, payment) as services (Dubbo, etc.)

8. Security Architecture

Infrastructure security – trusted hardware, hardened OS, network firewalls, DDOS protection, subnet isolation

Application security – prevent XSS, injection, CSRF, secure file uploads, use WAF (e.g., ModSecurity)

Data confidentiality – encrypted storage, regular backups, access control, transport encryption

Common algorithms – MD5, SHA, DES/3DES/RC (symmetric), RSA (asymmetric)

9. Agility

Architecture and operations must adapt quickly to business growth, traffic spikes, and feature changes.

10. Reference Seven‑Layer Architecture

1) Client layer (PC browsers, mobile apps) 2) Frontend optimization layer 3) Application layer 4) Service layer 5) Data storage layer 6) Big‑data storage layer 7) Big‑data processing layer.

11. Evolution of Large E‑Commerce Site Architecture

Early stage: single server hosts application, database, and files.

Later stages introduce separation of concerns, caching, clustering, read/write splitting, sharding, CDN, reverse proxy, distributed file systems, NoSQL, service extraction, and business splitting.

Cache implementation: local cache (e.g., OSCache) for speed, distributed cache (Memcached, Redis) for capacity.

Application clustering with load balancers (hardware F5, software LVS/Nginx/HAProxy). LVS operates at layer‑4, Nginx/HAProxy at layer‑7 with richer routing capabilities.

Database read/write separation and sharding to alleviate bottlenecks.

CDN and reverse proxy reduce latency for geographically dispersed users.

Distributed file systems (GFS, HDFS, TFS) handle massive file storage.

NoSQL (MongoDB, HBase, Redis) and search engines (Lucene, Solr, Elasticsearch) support large‑scale data queries.

Business splitting isolates functionalities (product, shopping, payment, comments, customer service, external interfaces) into independent subsystems.

Service mesh (e.g., Dubbo) provides distributed service framework.

12. Detailed E‑Commerce Case Study

Requirements include full B2C functionality, online payment, customer service chat, product reviews, integration with existing inventory system, support for 10 million users over 3‑5 years, and handling major sales events.

Capacity estimation (using 80/20 rule): 2 million daily UV, 30 page views per user → 60 million PV; peak traffic ≈ 8 340 requests/s.

Problems identified:

Need for many web servers during peak, leading to resource waste

Monolithic deployment causing tight coupling

Redundant code across applications

Session synchronization consuming memory and bandwidth

Database pressure from frequent reads/writes

Optimization measures:

Business splitting – separate core (product, shopping, payment) and non‑core subsystems

Application clustering – distributed deployment with RPC, at least two instances per service, load balancer for high availability

Multi‑level caching – local cache for immutable data, distributed cache (Redis) as second tier; cache‑auto‑expire and trigger‑expire strategies

Distributed session (SSO) – store session in Redis with expiration (e.g., 15 min)

Database clustering – master‑slave read/write separation, sharding per subsystem, horizontal partitioning of large tables

Serviceization – extract common functionalities as independent services

Message queue – async order processing, inventory deduction, and delivery via RabbitMQ/ActiveMQ

Additional techniques: CDN, reverse proxy, distributed file system, NoSQL for specific workloads

13. Summary

The architecture of a large website evolves with business growth; a typical design incorporates layered segmentation, clustering, multi‑level caching, stateless or distributed sessions, database sharding with read/write separation, service‑oriented components, message queues, CDN, reverse proxies, and robust security measures. This reference model helps engineers plan, evaluate, and iteratively improve large‑scale systems.