The problem

IT-Plus needed live online classrooms, not recorded video. A teacher and a full class had to share audio, video and interaction inside the same session, in the browser, without asking schools to install anything. Classrooms are also unforgiving about latency: a two-second delay is fine for a broadcast and fatal for a conversation. And the whole thing had to hold together as the room filled up, rather than degrading the moment more than a handful of students joined.

My role

I engineered the real-time layer of the Testat app end to end: the media flow, the signalling server, the session state, and the Angular interface teachers and students actually used. Real-time is one of those areas where the demo is easy and the production system is not, so most of the work went into the failure cases rather than the happy path.

Architecture

• WebRTC carries the audio and video, so media travels between participants directly instead of through an application server that would have become the bottleneck the moment a class grew.
• Socket.io handles everything WebRTC deliberately leaves undefined: signalling, peer discovery and session state — who is in the room, who is presenting, and who joined late and needs to be brought up to date.
• A Node.js service owns the room lifecycle and holds the authoritative view of session state, so a dropped connection rejoins into a correct room rather than a stale one. Browsers disconnect for reasons you cannot control; the server has to be the one place that knows the truth about a session.
• Live streaming alongside the interactive session, for the case where people need to watch rather than participate — a different traffic profile from a two-way call, and worth separating instead of pretending one mode fits both.
• The classroom interface is Angular, driven directly by real-time events rather than polling an endpoint and hoping the interval is short enough.

Technologies

Node.js, Socket.io, WebRTC, Angular.

Outcome

Testat sustained 50+ concurrent users per live session with live streaming — a real class, not a demo call between two laptops. The parts that decided whether it worked were the unglamorous ones: reconnection handling, keeping session state authoritative on the server, and treating signalling as its own concern instead of something bolted onto the media layer. It is still the project I point at when a client asks whether real-time in the browser is genuinely viable for their use case.