Implementation and Optimization of a High-Concurrency Live Quiz System

In early 2018, live‑quiz activities that combined video streaming with answer‑submission quickly became a low‑cost user‑acquisition method. Zhuanzhuan built a live‑quiz service within two weeks using Tencent's video live and IM channels.

The overall architecture adds a quiz layer on top of video live: each day several live sessions are scheduled, each session offers tens of thousands to millions of yuan in prize pools, with 1–12 questions per session. Participants have 10 seconds to answer; correct answers share the prize, while wrong or timed‑out answers can be revived using one or more “revival coins”.

Key business functions include:

Video live – streaming video via Tencent's live channel.

Question delivery – triggered by the quiz‑management backend and pushed through the IM channel; questions are never cached client‑side.

Answer submission – users submit within the 10‑second window (typically 2‑3 s reading, 7‑8 s answering), creating a massive concurrency load.

Answer distribution – the backend sends the correct answer, per‑option statistics, and revival‑coin usage back to clients.

Prize payment – a message‑queue (MQ) notifies a payment service to settle winnings in near‑real time.

Before each question the client must fetch the user’s revival‑coin balance and earned prize amount. Because the request spikes when the countdown reaches zero, the system randomises these requests during the 60‑second warm‑up period to smooth the load.

Answer submission is extremely time‑critical: with up to 200 000 concurrent requests per second, the service processes the following steps:

Validate that the submitted answer belongs to the current question and is within the answer window.

Retrieve the user’s previous answer record to detect repeats or jumps.

If the answer is wrong or the user timed out, check whether revival coins are available.

When revival coins are used, deduct them asynchronously via an MQ message.

Persist the current answer record.

Increment the count for the selected option.

The current‑question data, being small, is cached in‑process and synchronised from the database every 100 ms. Server‑side answer windows are slightly longer than the client‑side 10 s to accommodate network latency.

Revival‑coin deduction is performed asynchronously: the service publishes an MQ message, and a consumer updates the database later.

Global counting is stored in Redis. Each instance maintains a local atomic counter; every 100 ms or when the counter reaches 100, the value is flushed to Redis and the local counter reset, dramatically reducing Redis write frequency. In case of a crash, at most 100 ms of counts (or up to 100 items) may be lost.

User answer and revival‑coin information are also kept in Redis for speed. To avoid server‑side state, the backend returns an AES‑encrypted token containing user‑id, coin balance, last‑question id, and correctness flag. The client sends this token back with each answer; the server decrypts it, processes the logic, and returns a new token. Each quiz session can use a distinct encryption key.

Cheating scenarios are analysed (timeout, continued answering, duplicate submissions, multiple‑option submissions). The mitigation strategy sends all answer data through MQ, flags users who submit more than one option per question, adds them to a blacklist, and excludes them from payouts and future quizzes.

Because the synchronous part of answer handling stays in memory, 90 % of submissions complete in under 1 ms.

Tomcat optimization: three connector modes are available – BIO (blocking I/O), NIO (non‑blocking I/O), and APR (native I/O via JNI). In practice APR and NIO performed similarly, with APR slightly better, so the service runs Tomcat in APR mode for high‑concurrency workloads.

In summary, the high‑concurrency live‑quiz scenario is addressed with the following optimizations:

Distribute requests across time.

Use in‑process caching for hot data.

Process heavy tasks asynchronously.

Leverage MQ for peak‑shaving.

Aggregate counters in Redis.

Let the client store encrypted state tokens to reduce server load.

Author: Yang Yonggang, Zhuanzhuan Platform Service Technology Department.