Fundamentals and Evolution of Large-Scale Website Architecture

This piece serves as a brief summary of recent research on website architecture, focusing on core concepts and basic principles while acknowledging that the field is vast and the details involve various tools and development specifics.

How Did the Architecture Issue Arise?

Architecture emerged as society moved from the standalone PC era to the network era. In the early days, applications were isolated, distributed via floppy disks or CDs, and network speeds were too low for meaningful data transfer. Early software systems were crude, lacking any architectural thinking; they simply needed to run on a single machine.

With the advent of client/server (C/S) and browser/server (B/S) models, network speeds increased, massive numbers of users appeared, and web applications such as online games and e‑commerce proliferated. The rise of mobile devices further shifted focus from desktop OSes to a variety of endpoints, demanding new architectural approaches.

Modern websites must serve millions of users worldwide; a single point of failure can cause massive impact. Therefore, designers must consider performance, security, availability, scalability, and extensibility, which differ fundamentally from the concerns of the single‑machine era.

Even mobile apps rely heavily on web‑related technologies for integration, making mature, industry‑standard solutions preferable for rapid development and easy scaling.

Most architectural knowledge comes from large‑traffic sites, especially e‑commerce platforms, which have faced extreme load spikes (e.g., Alibaba’s Double‑11 event) and thus pioneered techniques for handling massive concurrency and data volumes.

What Is the Core Philosophy of Website Architecture?

Architecture is the continual process of identifying system bottlenecks and weaknesses, then applying partitioning, caching, asynchronous processing, and other techniques to resolve them while balancing performance, security, availability, scalability, and extensibility.

In simple terms: design and plan the system, understand what needs to be built, avoid over‑design, and tailor solutions to your own business rather than copying large sites blindly.

The typical request flow is:

Browser request → DNS resolution → Browser connects to server → Server accesses database → Server computes result → Data returned to browser. Each step offers opportunities for scaling, partitioning, and optimization.

DNS resolution can route users to geographically appropriate servers.

Browser‑to‑server connection can use load balancers and reverse proxies to distribute traffic across a server cluster.

Server‑to‑database access can employ read/write splitting, NoSQL caches, and data sharding.

Server computation can leverage appropriate languages, caching, message queues, RPC, and asynchronous processing.

Response to browser can be accelerated with CDNs and aggressive client‑side caching.

Each of these stages involves specialized knowledge and a variety of professional tools and services.

Common Evolution Paths of Website Architecture

The following diagrams (originally from Li Zhihui’s book “Large‑Scale Website Architecture – Core Principles and Case Studies”) illustrate typical stages, though they are not rigid templates and should be adapted to specific business needs.

1. Initial website architecture

2. Separation of application and data services

3. Introduction of caching

4. Deployment of application server clusters

5. Database read/write separation

6. Use of reverse proxies and CDN acceleration

7. Distributed file and database systems

8. Adoption of NoSQL and search engines

9. Application decomposition (micro‑services)

10. Distributed services

Common Toolkits Used in Website Architecture

Tool selection depends on specific business requirements, but most widely used products run on Linux and are open‑source, often written in Java. Smaller sites may use PHP for its ease and lower cost. Popular components include Redis for caching, various NoSQL databases, message queues, reverse proxies, load balancers, and CDN services.

Other toolkits should be evaluated and adopted as needed, and the architecture will continue to evolve with emerging technologies.

Source: http://www.epubit.com.cn/article/1481

Copyright notice: Content originates from the web; rights belong to the original authors. We attribute sources unless unable to confirm, and will remove infringing material upon request.