How to Build a High‑Concurrency Live Quiz System: Architecture & Tech Stack
This article explains the product features, technical challenges, technology choices, and detailed architecture design for a live‑streaming quiz application that must support up to one million concurrent users, high QPS, low latency, and secure financial transactions.
Product Overview
The live‑quiz app offers simple gameplay: real‑time PK, 10‑second answering window, instant elimination on wrong answer, and prize sharing for correct answers, plus features such as live chat, red‑packet rain, and invitation rewards.
Technical Challenges
Audio‑video processing and transmission (encoding, real‑time beautification, CDN acceleration, device adaptation).
High concurrent requests: up to 1 million online users, 200 k QPS for answering, and up to 500 k QPS for red‑packet clicks.
High bandwidth demand: > 970 Gbps for video streams and > 19 Gbps for barrage messages.
High computational load for answer validation, anti‑cheat logic, and result calculation.
Accurate and secure financial flow for prize distribution.
Low‑latency synchronization of video, audio, and business data.
Minimal interference with existing e‑commerce transaction systems.
Technology Selection
Audio‑video is outsourced to Tencent Cloud live solution. Business data uses a custom long‑connection channel built with Netty, Protocol Buffers, and WebSocket to handle millions of concurrent users.
Architecture Design
The system separates video and business data streams. Video uses the cloud provider’s CDN; business data is transmitted via a TCP gateway that maintains long connections, balances load with Nginx, and forwards messages to the quiz service via RPC.
Message format is unified with a top‑level Message that wraps Request, Response, and Notification types, each identified by a MessageType enum and a unique sequence number.
message Message {
MessageType messageType = 1; // enum
string sequence = 2; // unique id
Request request = 3;
Response response = 4;
Notification notification = 5;
}High‑Concurrency Solutions
All answer‑related logic operates on cache only (Write‑Behind caching) and syncs to DB asynchronously.
Multi‑level caching: local + Redis, with pre‑warming of static data.
Redis master‑slave + Sentinel for high availability; separate Redis instances per business module.
Optimized request flow: prioritize cheap checks, defer expensive validation.
Answer result is calculated during the 10‑second answer window and pushed immediately, encrypted with XOR, and the decryption key is released only when the host announces the correct answer.
Red‑packet handling uses pre‑computed amounts stored in Redis, client‑side and server‑side rate limiting, and Lua scripts for atomic operations.
Deployment
A hybrid private‑cloud + public‑cloud deployment isolates the high‑traffic quiz services in the public cloud while keeping core e‑commerce services on‑premises, connected via dedicated network lines for elastic scaling.
Takeaways
Use cloud video services for basic streaming, focus architectural effort on business data flow, adopt long‑connection protocols (Netty + WebSocket + ProtoBuf), and design every component with peak‑load capacity in mind.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
