Building QQ Front-end Unified Access Layer: Architecture, Technical Choices, and Performance Insights

The author reflects on ten years of experience building large‑scale gateway systems, from handling a thousand daily calls to supporting hundreds of millions of DAU, and aims to share practical insights rather than abstract theory.

Business background : The legacy QQ client SDK lacked cross‑platform support, prompting the creation of a unified NT layer to consolidate SDKs and reduce duplicated Node services, which had grown to over 300 instances.

Overall architecture : The front‑end access layer is designed as a stable, high‑performance system with considerations for scalability, security, and maintainability, leaving room for future extensions such as overseas versions.

Solution comparison : The author compares open‑source and internal options, highlighting why nginx‑based APISIX and the internally developed http2rpc were chosen for their balance of performance, flexibility, and integration cost.

Core difficulties : Challenges include observability, alerting, and performance; the lack of feedback loops hampers iteration, while optimizing generic scenarios is hard, yet specific use‑cases can achieve significant gains.

Observability & alerting : Implementing log‑based alerts uncovered a hidden idle‑connection bug in tRPC, improving availability, but also introduced alert fatigue, leading to the need for feedback‑driven alert management.

Performance : The author emphasizes that while universal optimizations are difficult, targeted improvements—such as time‑offset based push for map‑type games—can dramatically reduce device heating and latency.

Finally, the article includes a brief promotion for a DevOps certification class, encouraging readers to deepen their full‑stack and operational skills.