Key Characteristics, Technical Challenges, and Evolution of Large-Scale Website Architecture

Key Characteristics of Large Websites

High concurrency and massive traffic: must handle many simultaneous users and large volumes of requests.

High availability: require 24/7 uninterrupted service.

Massive data: large storage and management needs, often requiring many servers.

Diverse user distribution and complex network conditions: global networks and inter‑operator connectivity issues.

Harsh security environment: openness of the Internet makes sites vulnerable to attacks.

Rapid requirement changes and frequent releases: fast iteration cycles.

Progressive growth: start as a small site and evolve into a large‑scale platform.

Main Technical Challenges of Large Websites

Enormous user bases, high‑frequency access, and petabyte‑level data make even simple business logic difficult to handle at scale.

Evolution of Large‑Site Architecture

Initial Stage Architecture

Most small projects start with a single server; as traffic grows, one server can no longer meet demand, leading to performance degradation and storage shortages.

Separation of Application, Database, and File Services

Separate application services from data services to improve performance and solve storage issues (server specialization).

Application servers: handle business logic, require strong CPU.

File servers: store files, require large storage capacity.

Database servers: store data, cache, and perform disk retrieval; require fast memory and disks.

As user volume increases, database load becomes a bottleneck.

Improving Performance with Caching

According to the 80/20 rule, 80% of accesses target 20% of data, so caching frequently used data reduces database pressure.

Two types of cache:

Local cache: faster access but limited by application server memory and may compete with the application for memory.

Distributed cache: cluster of dedicated cache servers, theoretically not limited by a single node’s memory.

When only a single application server instance is deployed, its connection capacity is limited, making it a bottleneck during traffic peaks.

Using Application Clustering to Enhance Concurrency

When a single server cannot keep up, adding more servers is preferable to upgrading to a more powerful one; large sites require horizontal scaling to meet continuous growth.

Database Read/Write Splitting

Even with caching, some reads (cache miss, expiration) and all writes still hit the database, which can become a bottleneck at scale.

Solution: configure master‑slave replication, directing writes to the master and reads to one or more slaves, with data synchronized from master to slaves. Applications can use a dedicated data‑access layer to transparently handle the split.

Reverse Proxy Cache and CDN Acceleration

Different network environments cause varying access speeds for users.

Solution: employ reverse‑proxy caching and CDN to accelerate responses.

Both act as caches; CDNs are deployed in ISP data centers close to users, while reverse proxies sit in the site’s central data center, serving cached resources before they reach the application servers.

The goal is to return data to users as early as possible, improving perceived speed and reducing load on application servers.

Distributed File System and Distributed Database Systems

As the site grows, the existing read/write‑split database and file servers can no longer meet demand.

At this stage, distributed databases and distributed file systems become necessary.

Distributed databases are a last‑resort for extremely large tables; more commonly, business‑level sharding places different business data on separate physical servers.

Using NoSQL and Search Engines

Increasingly complex business logic demands more sophisticated data storage and retrieval, prompting the adoption of NoSQL solutions and search‑engine technologies.

Business Splitting (Divide and Conquer)

When a website becomes overly complex, split the business into independent lines (e.g., homepage, shop, order, buyer, seller) managed by separate teams. Technically, this translates to multiple independent applications, each deployed and maintained separately.

Interactions between applications can be achieved via hyperlinks, message queues, or shared data stores.

Distributed Services

As business modules become finer‑grained and storage systems grow, overall system complexity increases exponentially, making deployment and maintenance harder. With tens of thousands of servers, database connections become a scarce resource.

Common functionalities (e.g., user management, product management) can be extracted into independent services and deployed separately.