Designing a Deployment Architecture for a System Handling 50 Million Daily Requests

Estimating Required QPS

For a system with 50,000,000 daily requests, the average QPS is calculated as 50,000,000 ÷ (24×60×60) = 578 QPS. Assuming peak traffic is 5× the average, the peak QPS becomes 578 × 5 = 2,890. Adding a safety factor of 1.5 for burst traffic yields a design target of 2,890 × 1.5 ≈ 4,470 QPS.

Deployment Topology

The proposed architecture consists of a traffic‑entry layer, a business‑logic layer, a caching layer, a database layer, and an asynchronous messaging layer, as illustrated in the diagram below.

Traffic‑Entry Layer

LVS (Linux Virtual Server) is used as the first load balancer; a two‑node LVS cluster (active‑passive) provides high availability and can handle roughly 100,000 QPS. Behind LVS, three Nginx instances are deployed; each Nginx can sustain 1–2k QPS, giving a combined capacity of about 9,000 QPS, comfortably above the 4,470‑QPS target.

Business‑Logic Layer

Requests forwarded by Nginx reach a gateway that distributes them to the application servers. After optimization, a single 4‑core 8 GB machine can process 1,500–2,000 QPS. Deploying three such servers meets the peak requirement, and a fourth server is added as a buffer for unexpected spikes. The servers run inside Docker containers managed by Kubernetes (K8s).

Caching Layer

Redis is introduced as a cache to offload frequent read traffic (e.g., product detail pages). A single Redis instance can handle around 100,000 QPS, but to avoid a single point of failure a Redis cluster is used. Cache entries are given appropriate TTLs, and strategies for cache‑penetration, cache‑breakdown, and cache‑avalanche are applied.

Database Layer

MySQL stores persistent business data. A single MySQL node supports roughly 1,000–2,000 QPS. To handle the 4,470‑QPS load, a master‑slave cluster with one primary and two replicas is built, employing sharding and table partitioning to distribute write load.

Asynchronous Messaging Layer

Kafka or RocketMQ is used for peak‑shaving and decoupling. These message queues absorb burst traffic, buffer it, and allow downstream services to process tasks asynchronously.

Key Takeaways

System deployment must be driven by a calculated peak QPS (≈4,470 QPS for 50 M daily requests).

High‑concurrency systems benefit from a multi‑layered load‑balancing strategy (LVS + Nginx) and containerized application servers.

Cache (Redis) and database (MySQL) layers should be scaled and clustered to meet read/write demands.

Message queues (Kafka/RocketMQ) provide peak‑shaving and decoupling for asynchronous workloads.