Xây Real-time Interactive Quiz App với WebSocket/SSE cho hàng nghìn học sinh
Hướng dẫn xây real-time interactive quiz chịu tải lớn bằng WebSocket/SSE, Redis Pub/Sub/Streams, horizontal scaling, reconnect, backpressure, anti-cheat và load testing.
ShanverseUpdated 11 min read— viewsLoading views
WebSocket
Server-Sent Events
EdTech
WebSocket hay SSE?
Với quiz lớp học, hai lựa chọn đều hợp lý:
WebSocket toàn phần: host/player cùng gửi và nhận event trên socket.
SSE + HTTP: server phát câu hỏi/timer/score qua SSE; client gửi đáp án bằng POST. Cách này đơn giản, dễ retry/idempotency và tận dụng hạ tầng HTTP.
Hybrid: WebSocket cho host/control plane, SSE cho hàng nghìn player chỉ cần nhận broadcast, HTTP POST cho đáp án.
SSE là một chiều; dưới HTTP/1.1, trình duyệt có giới hạn kết nối thấp theo origin, nên ưu tiên HTTP/2 hoặc chỉ mở một stream mỗi tab.[1]
Comments
Yêu cầu tải thực tế
Giả sử:
10.000 học sinh trong 100 phòng.
Mỗi phòng 100 người.
1 host mở câu hỏi mỗi 20 giây.
80% đáp án đến trong 3 giây cuối.
Mỗi event 0,5–2 KB.
Average throughput không cao, nhưng peak có thể đạt hàng nghìn answer/giây cùng lúc. Capacity planning phải đo:
Concurrent connections.
Connection establishment/second.
Broadcast fan-out messages/second.
Answer write peak và p95/p99 acknowledgment.
Reconnect storm sau deploy/mạng chập chờn.
Memory/file descriptor/event-loop lag trên gateway.
Kiến trúc tổng thể
Mermaid
Loading diagram…
Thành phần:
Realtime Gateway: giữ kết nối, authenticate, validate envelope, fan-out.
Quiz Orchestrator: nguồn sự thật cho state machine của phòng.
Answer Service: nhận và deduplicate đáp án.
Score Aggregator: chấm sau khi câu hỏi khóa, tạo projection bảng điểm.
Room Bus: đưa event giữa gateway và room owner.
Durable store/event log: phục hồi state và replay khi reconnect.
Redis: presence, membership, cache và fan-out nhanh; không phải nguồn sự thật duy nhất.
State machine phải do server làm chủ
Mỗi transition có version tăng dần và thời điểm hiệu lực:
Client không tự quyết định hết giờ dựa vào countdown. Server gửi closesAt UTC; UI render countdown từ clock estimate, nhưng server quyết định đáp án có được nhận hay không. Dùng một Orchestrator/partition owner cho mỗi room để tránh hai node cùng mở câu hỏi.
Protocol event có version và sequence
Các event chính:
sequence giúp client phát hiện gap. Sau reconnect, client gửi lastSequence. Server replay từ log ngắn hạn hoặc trả room.snapshot mới. Không dựa vào thứ tự arrival giữa nhiều channel.
Answer API: idempotent và server-authoritative
Dù qua WebSocket hay HTTP, mỗi câu trả lời phải có idempotency key:
Schema database:
Handler:
Không dùng clientSentAt để quyết định deadline vì có thể giả mạo. Có thể áp dụng grace window nhỏ dựa trên latency estimate, nhưng policy phải nhất quán và audit được. Server không gửi đáp án đúng xuống client trước khi khóa câu hỏi.
Scoring công bằng và deterministic
Một công thức phổ biến:
Quy tắc:
Dùng received_at do server ghi.
Clamp thời gian trong khoảng câu hỏi.
Version scoring rule theo room/quiz.
Không tính lại với rule mới cho trận đã kết thúc.
Tie-break rõ ràng: correctness, total score, tổng thời gian hoặc đồng hạng.
Leaderboard chỉ phát sau khi question locked và answer batch đã chấm.
Để tránh leak, event question.opened không chứa correct option/rubric. Event answer.revealed chỉ phát sau transition.
WebSocket gateway tối giản
Production cần:
Xác thực token trong HTTP upgrade; token ngắn hạn, scoped cho room/role.
Validate Origin đối với browser client.
Payload size limit, schema validation và per-event authorization.
Ping/pong heartbeat, idle timeout và cleanup.
Per-connection outbound queue có giới hạn.
Không block event loop bằng chấm bài nặng, JSON khổng lồ hoặc synchronous I/O.
Browser WebSocket API không có backpressure tự động; nếu message tới nhanh hơn client xử lý, bộ nhớ/CPU có thể tăng mạnh.[2] Vì vậy, hãy coalesce timer/presence update, drop event low-priority cũ, giới hạn queue và disconnect slow consumer để client resync.
SSE endpoint và resume
SSE standard hỗ trợ id và Last-Event-ID khi reconnect.[3] Reverse proxy phải không buffer stream; heartbeat phải ngắn hơn idle timeout. Với NGINX WebSocket, proxy cần chuyển Upgrade/Connection và kết nối mặc định có thể bị đóng nếu upstream im lặng quá lâu; dùng ping hoặc điều chỉnh proxy_read_timeout.[4]
Scale ngang: room ownership và fan-out
Không lưu room state chỉ trong RAM của gateway. Có hai pattern:
Pattern A — Stateless gateways
Mọi gateway nhận connection bất kỳ.
Event room đi qua Redis Pub/Sub/NATS/Kafka.
Gateway subscribe room có local clients.
Durable state nằm ở Orchestrator/database.
Đơn giản nhưng subscribe cardinality và cross-node fan-out cần kiểm soát.
Pattern B — Shard theo room
Consistent hash roomId → room owner.
Gateway route command tới owner.
Owner serialize state transition của room.
Fan-out qua bus tới gateway có participant.
Pattern này giảm contention và giữ ordering theo room. Khi owner fail, lease/epoch ngăn “split brain”; owner mới rebuild state từ snapshot + event log.
Sticky session có thể giảm fan-out nội bộ nhưng không được là điều kiện đúng/sai. Khi node chết, client phải reconnect node khác và resume.
Redis Pub/Sub hay Redis Streams?
Redis Pub/Sub phù hợp tín hiệu live nhưng có delivery at-most-once; subscriber offline sẽ bỏ lỡ event.[5] Vì vậy:
Dùng Pub/Sub cho presence/timer update có thể bỏ qua và được thay thế bởi snapshot mới.
Dùng Redis Streams/Kafka/database event log cho event cần replay như question transition, accepted answer và score result.
Mô hình hybrid: durable stream là nguồn sự thật; Pub/Sub là “chuông cửa” giúp fan-out nhanh.
Không ghi từng tick countdown vào broker. Chỉ gửi openedAt/closesAt; client tự render. Điều này giảm fan-out từ 10.000 message/giây xuống gần như một event mỗi question.
Reconnect không tạo thundering herd
Client reconnect bằng exponential backoff + jitter:
Ngoài ra:
Server trả Retry-After khi quá tải.
Token refresh không đồng bộ cùng một thời điểm cho cả lớp.
Gateway giới hạn handshake/second theo IP/tenant/room.
Client resume bằng sequence/snapshot, không replay toàn bộ quiz.
Deploy dùng connection draining: ngừng nhận socket mới, báo reconnect sau khoảng ngẫu nhiên, rồi đóng.
Presence và participant count
Presence là eventually consistent. Không ghi heartbeat vào PostgreSQL. Dùng TTL key hoặc connection registry trong Redis:
Một participant có thể mở nhiều tab; đếm participant duy nhất, không đếm socket. Hiển thị “khoảng 1.200 người đang online” nếu consistency không tuyệt đối. Presence không được ảnh hưởng quyền submit answer; authorization dựa trên session/membership bền vững.
Bảo mật và chống gian lận
Join code chỉ dùng để tìm room; đổi thành participant token có hạn ngắn.
Phân quyền host, cohost, participant, spectator cho từng command.
Host command cần optimistic version/nonce để tránh double-click mở hai câu.
Không gửi question bank/correct answer hàng loạt xuống browser.
Rate limit join, answer, chat và host commands riêng.
Sanitize nickname/user-generated content trước khi render; tránh XSS.
Chống replay bằng requestId và unique key.
Audit host actions, late answer, score adjustment và moderation.
Không tin client timer, score hoặc room phase.
DDoS/WAF ở edge, connection quota theo tenant và circuit breaker khi downstream chậm.
Với trẻ vị thành niên, dùng nickname mặc định, không công khai PII, có chế độ ẩn leaderboard và retention ngắn cho dữ liệu phòng.
Load test đúng kiểu quiz
HTTP benchmark đơn thuần không mô phỏng được socket lâu dài và burst. Dùng k6 WebSockets hoặc công cụ tương đương; k6 có module WebSocket với global event loop cho nhiều kết nối đồng thời.[6]
Kịch bản:
Ramp 0 → 10.000 connection trong 5 phút.
Join 100 room với phân phối thực tế.
Host đồng loạt mở câu hỏi.
80% client submit trong 3 giây cuối.
10% connection rớt rồi reconnect với jitter.
Một gateway bị kill giữa vòng.
Redis/broker tăng latency hoặc failover.
Kết thúc, chấm và phát leaderboard.
Đo:
Handshake success và thời gian join.
Question fan-out p50/p95/p99 và tỷ lệ client nhận trước deadline.
Answer acknowledgment p95/p99.
Duplicate acceptance phải bằng 0.
Event gap/resync rate.
Event-loop lag, CPU, RSS, GC, FD và outbound queue.
Broker lag, Redis ops, DB connection pool.
Reconnect recovery time.
Success criterion ví dụ: 99,9% client nhận question.opened trong 500 ms, 99% answer hợp lệ được ack trong 250 ms ở peak, không xử lý trùng và room phục hồi dưới 5 giây. Ngưỡng thực tế phải dựa trên SLA và vùng địa lý.
Observability
Mỗi event có eventId, roomId, participantId dạng pseudonymous, sequence, roomVersion và correlation ID. Dashboard theo dõi:
Active connections/node và connections/room.
Inbound/outbound messages, bytes và drops.
Slow consumers và queue depth.
Room transition latency.
Answer accepted/rejected theo reason.
Score aggregation lag.
Pub/Sub/Stream lag và dropped messages.
Reconnect, resync và auth failures.
Không log nội dung đáp án/nickname đầy đủ nếu không cần. Sample trace theo room thay vì trace mọi heartbeat.
Chiến lược triển khai
Giai đoạn 1 — Single region, modular service
Một realtime service + PostgreSQL + Redis.
State machine authoritative, answer idempotent.
WebSocket hoặc SSE+POST, chưa cần nhiều broker.
Giai đoạn 2 — Horizontal gateways
Room bus, stateless gateway, Redis presence.
Durable transition log và reconnect snapshot.
Autoscaling theo active connections + event-loop lag, không chỉ CPU.
Giai đoạn 3 — Room sharding
Partition room owner, lease/epoch và failover.
Score workers, replay/rebuild và cross-zone test.
Capacity isolation cho tenant/room lớn.
Giai đoạn 4 — Multi-region
Pin room vào một home region để giữ ordering.
Edge route participant tới home region.
Không active-active write cùng room nếu chưa có conflict protocol.
Disaster recovery bằng snapshot/event log; đo RTO/RPO.
Checklist production
Lựa chọn rõ WebSocket, SSE+POST hoặc hybrid
Server-authoritative room state machine và deadline
Event envelope có protocol version, sequence và roomVersion
Submit answer idempotent với unique constraint
Correct answer không bị gửi trước reveal
Durable transition/answer log; Pub/Sub chỉ cho ephemeral fan-out
Reconnect resume bằng event ID/sequence hoặc snapshot
Backpressure policy và slow-consumer handling
Heartbeat, proxy timeout và connection draining
Horizontal scaling không phụ thuộc sticky session
Rate limit, RBAC, origin validation và output sanitization
Load test synchronized burst, reconnect storm và node failure
SLO cho fan-out, answer ack, recovery và data integrity
Kết luận
Một quiz thời gian thực quy mô lớn cần tách connection, authoritative room state, durable answer ingestion và ephemeral fan-out. WebSocket phù hợp giao tiếp hai chiều; SSE+POST thường đơn giản và mạnh cho mô hình server broadcast + client submit. Dù chọn protocol nào, độ tin cậy đến từ sequence, idempotency, snapshot/replay, backpressure và load test mô phỏng đúng khoảnh khắc cả lớp bấm đáp án cùng lúc.
Nên chọn HTTP Long-Polling, Server-Sent Events hay WebSocket? Phân tích kiến trúc, hiệu năng, scaling, bảo mật, code Node.js và decision tree cho ứng dụng real-time.
