Introduction
I've compiled some notes on high-traffic website architecture design. The common theme seems to be "divide and conquer"—breaking down large components into smaller ones. This involves splitting up tasks or bottlenecks to make the system or services easy to scale horizontally, avoiding overload at a single point which can create a system bottleneck. This is actually similar to large organizations in the real world; when they hit a growth bottleneck, they have to restructure.
Frontend
- Frontend optimizations, such as optimizing images, JS, CSS, lazy loading, and static page generation.
- Use a CDN to host static content, reducing the I/O pressure on the main server.
Backend
- Adopt mature programming language frameworks and write asynchronous code to maximize CPU and I/O utilization. Don't send unnecessary data to the frontend. If data can be fetched in a single request, don't use multiple requests.
- Adopt a distributed architecture - break down the application into multiple independent services to prevent one service from getting stuck and causing a system bottleneck. For example: a payment module, a logistics module.
- Use queuing technologies - when the system receives a large number of requests in a short time, a queue can temporarily store these requests and then process them gradually according to the system's capacity, avoiding sudden spikes in usage that could impact the system.
- You can use certain algorithmic patterns to handle sudden performance bottlenecks: circuit breaking, bulkheading, retries, graceful degradation, timeouts, and rate limiting (token bucket, waiting room, leaky bucket)
Database
- Database performance optimization. For example: creating indexes, optimizing queries, denormalization, reducing joins, vertical table partitioning, or using a caching server to cache data that doesn't change often, avoiding fetching it from the DB every time.
- The database can be sharded or partitioned into multiple databases to distribute data processing.
- Read-write splitting - Separate database reads and writes, using Master-Slave Replication to handle a large volume of read requests.
- Use NoSQL databases. NoSQL is effective for partitioning and sharding, has horizontal scaling capabilities, and is particularly suitable for handling large-scale data, such as user profiles.
- Ensure transactional consistency using locking mechanisms
Caching
- Frontend Caching - Enable client-side caching. If a file hasn't changed, the client doesn't need to request it again.
- Backend Caching - For data that is frequently queried but rarely changes, a caching server can be used, or use a Redis Cluster for data sharding (suitable for scenarios with contiguous Redis keys).
Operations
- Load Balancer - The core principle of load balancing is to distribute traffic and tasks across multiple servers using a reverse proxy mechanism. If the QPS is less than 10k, it's recommended to use a software reverse proxy (like Nginx or YARP). Hardware load balancers have specially designed chips that can handle much higher traffic loads. When QPS exceeds 10k, you should consider purchasing a hardware load balancer, such as an F5.
- Adopt a modern system operations architecture (K8s) to scale out and in based on QPS or system resources.
- Service Monitoring (Health Check) - Promptly detect and respond to service anomalies to ensure stable operation. For example: Uptime-Kuma
- Application Observability - Provides visualization and analysis of application performance, facilitating problem diagnosis and performance optimization. For example: Signoz, Prometheus
- Log Server - Centralizes log management and analysis, making it easier to find and trace the source of issues. For example: Grafana, SEQ
Security
- Use a website protection service like Cloudflare to prevent malicious attacks, such as DDoS.
- Prevent CSRF attacks to enhance system security.
Finally
To be honest, there are some features here that I haven't implemented myself, but I've compiled this list to give myself a conceptual map. This way, when I encounter these problems, I'll at least have a starting point for a solution. However, not every website needs this kind of architecture. A design that is too granular can increase maintenance costs. Instead, it's more appropriate to consider future business volume when evaluating this type of website architecture.
Comments