Real-Time Classroom Quiz with Presence and Reconnect Handling
Live quiz tools are used in almost every classroom, and they fail in the same place: forty phones on weak campus Wi-Fi, a few disconnecting mid-question, and a leaderboard that disagrees with what students saw. Build a real-time quiz app where a teacher runs a session, students join with a code, and the server stays the single source of truth through presence, reconnects and late answers. A focused project on WebSocket engineering that is easy to test with real users.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 to 3 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- Quiz authoring and live sessions that students join by code from a phone browser without an account
- Server-authoritative timers and scoring that ignore client timestamps
- Presence showing connected, answered and dropped students, driven by heartbeats
- Reconnect and resume that restores the current question and score without creating a duplicate participant
- A documented message protocol with sequence numbers and a session state diagram
- A load test with at least 300 simulated clients in one session, reporting message latency and loss
- A trial in a real class, with what the teacher saw compared against what the server recorded
If you have time left
- Two server instances sharing session state through Redis pub/sub, so a session survives one instance restarting
- Team mode, and questions with images or code snippets
- A mode tested with screen reader users
- Exporting results to a spreadsheet the teacher already uses
Problem
A teacher starts a quiz, forty students join from their phones, and the room's Wi-Fi drops connections every few minutes. Students who reconnect see the wrong question, answers submitted a second after the timer are sometimes accepted and sometimes not, and the final leaderboard is disputed. Real-time apps are easy to demo with two browser tabs and hard to get right with forty unreliable clients.
What you build
- Teachers create quizzes with multiple choice and numeric questions and start a live session with a join code.
- Students join from a phone browser without creating an account.
- The server pushes each question, runs the timer, accepts answers and reveals results.
- Presence: the teacher sees who is connected, who has answered and who has dropped.
- Reconnect handling: a student who drops and returns during the session resumes on the correct question with their score intact.
- A live leaderboard and a report per question after the session.
This is different from a collaborative editor or whiteboard. There is no shared document to merge: the server is authoritative, and the challenge is keeping many flaky clients consistent with it.
Suggested architecture
- Node.js with the ws library, React on the client, PostgreSQL for quizzes and results, and Redis for live session state. Socket.IO is an acceptable alternative if you document what it does for you.
- Every server message carries a sequence number. On reconnect, the client sends the last sequence it saw and the server replies with the current state, not a replay of every event.
- Timing is decided on the server. Never trust a timestamp sent by a phone.
- Heartbeats every few seconds, so presence reflects reality instead of waiting for a TCP timeout.
- Rate limit answer submissions and check that each answer belongs to the question currently open.
Milestones by month
- Month 1: quiz authoring, session creation, joining by code, basic WebSocket messaging.
- Month 2: server-run timers, answer handling, scoring, leaderboard.
- Month 3: presence, heartbeats, reconnect and resume, network fault testing.
- Month 4: load test with simulated clients, classroom trial, report and demo.
How it will be assessed
- A demo where students are disconnected on purpose, with airplane mode or by closing the tab, and rejoin on the correct question with correct scores.
- A load test with at least 300 simulated clients in one session, reporting message latency and dropped messages.
- A trial in at least one real class, comparing what the teacher saw with what the server recorded.
- A report explaining the message protocol and every state transition of a session.
Pitfalls
- Testing only on localhost. Use browser network throttling and a phone on mobile data.
- Broadcasting the full state on every change, which falls over as the room grows.
- Letting a reconnect create a second participant with a score of zero.
- Sending correct answers to the client before the question closes.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.