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.

Programmer DD
Programmer DD
Programmer DD
How to Build a High‑Concurrency Live Quiz System: Architecture & Tech Stack

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Backend Architecturelive streamingProtobufhigh concurrencyWebSocket
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.