Designing a Scalable Architecture for Million‑to‑Billion‑Level DAU Systems

This article analyzes why recent large‑scale service outages occurred, attributing them to insufficient scalability and lack of automatic scaling, and then presents a systematic architecture that can sustain million‑level DAU and scale to tens or hundreds of millions.

Layer 1 – DNS: DNS resolves user IPs to regional data centers, ensuring traffic is directed to the appropriate IDC and leveraging client‑side caching for stability.

Layer 2 – L4 Load Balancing: Software load balancers such as LVS (≈100k+ QPS per instance) or hardware F5 devices (≈1M+ QPS) forward traffic based on domain names to downstream L7 gateway clusters.

Layer 3 – L7 (Gateway) Load Balancing: Nginx‑based gateway clusters handle application‑level routing, providing per‑service or per‑API load distribution, authentication, logging, and monitoring.

Layer 4 – Service Tier: After gateway routing, requests reach the actual service instances, which can be deployed as a monolith for simple cases or split into micro‑services when codebase size or team size grows.

Layer 5 – Caching: Frequently accessed data is cached in systems like Memcached or Redis (≈100k QPS, 1‑2 ms latency) to reduce database load.

Layer 6 – Database: High‑availability databases employ master‑slave replication for read‑write separation, and sharding/partitioning (by time or user ID) to keep individual tables under tens of millions of rows, supporting T‑scale storage.

Hybrid‑Cloud Architecture: To overcome private‑cloud bandwidth limits, traffic can be off‑loaded to public‑cloud resources when private‑cloud egress is saturated, requiring seamless network connectivity and a unified deployment platform such as BridgX.

Full‑Chain Elastic Scaling: All layers (L4/L7, services, cache, DB) must support automatic scaling; techniques include weighted QPS calculations, machine‑learning‑driven capacity prediction, and open‑source tools like CudgX for precise auto‑scaling.

Three‑Tier Degradation Mechanism: When scaling cannot keep up, the system can degrade gracefully: Level 1 (invisible to users, ≤30% capacity release), Level 2 (user‑visible, ≤50% release), Level 3 (major degradation, 50‑100% release) to preserve core functionality.

Overall, combining these layers with robust monitoring, alerting, and decision‑support systems enables a resilient architecture capable of handling sudden traffic spikes for DAU counts ranging from millions to billions.