Backend Design and Implementation of QQ Game Spring Festival Red Packet System

The article presents a comprehensive backend design for the QQ Game Spring Festival Red Packet activity, which celebrates QQ's 18th birthday on February 10. It describes the overall architecture, functional requirements, performance constraints, fault‑tolerance mechanisms, and monitoring solutions.

1. Requirement Background – Three types of red packets (Swipe, AR map, Scan) are offered. Users receive a coupon that displays a list of game gift packs; after selecting a pack, a server‑side component validates the user’s region and role before delivering the reward within 48 hours. The system must handle an entrance traffic of 80 k requests per second (RPS).

2. Requirement Analysis – The gift‑list is generated from offline static data distributed via CDN. The backend must filter and sort gifts based on user registration status (new‑user vs. active‑user) and user preferences using a two‑level sorting algorithm (registration‑based first, then a preference‑based “ShenDun” algorithm). Region‑server information is cached in CMEM with a multi‑level cache to reduce load on the slow IDIP service.

3. Overall Solution & Project Phasing – The project is divided into four iterative phases: functional development, performance (asynchronous delivery) development, fault‑tolerance development, and monitoring development. Each phase has its own milestone and load‑testing requirements.

4. Development Details

4.1 Functional Development – The backend gift‑recommendation interface must be consistent with the AMS qualification‑check interface. Data is reorganized in a separate CMEM instance where the key is the user ID and the value is the list of registered game IDs, enabling a single lookup for all ten games.

4.2 Performance Development – The activity generates up to 96 k RPS for gift‑claim requests, while the combined game‑side delivery capacity is only about 5 k RPS. To bridge this gap, a buffering queue (RocketMQ) is introduced. Requests are validated by AMS, placed into the queue, and then processed by a daemon that throttles delivery to stay within game‑side limits.

4.3 Fault‑Tolerance Development – To avoid over‑delivery and loss, each claim generates a globally unique order ID stored in CMEM. Idempotent checks prevent duplicate deliveries. A reconciliation process compares “should‑send” and “actual‑send” logs, subtracts queued but unprocessed items, and generates a resend list. The system also includes security checks (login verification, high‑value item protection) and strict permission controls (machine‑level authentication, key‑based API access).

4.4 Monitoring Development – A unified monitoring view aggregates key metrics from all subsystems (frontend, backend, AMS, MQ, etc.). Interfaces are wrapped into a key‑value query model, and configuration files define time windows and metric IDs for each activity. This enables real‑time visibility of conversion funnels, request volumes, queue depth, and delivery success rates.

The article concludes with a summary of the architecture, lessons learned, and a preview of the next installment.