Design a Real-Time Interactive Classroom

Problem statement

Design a real-time interactive classroom where a teacher broadcasts audio and video, shares slides or a live whiteboard, sees student state such as presence and hand raises, runs Q&A and chat, splits the class into breakout rooms for small-group work, and closes the session with attendance and an optional recording. Students join from laptops and phones on home Wi-Fi, campus networks, and weak cellular links.

The trap in this question is drawing one big WebSocket box and calling it real time. A classroom is two planes with different physics. The control plane carries session lifecycle, roster, chat, hand raises, breakout membership, quiz events, and attendance. It tolerates hundreds of milliseconds and can be rebuilt from durable state. The media plane carries live audio, teacher video, screen share, and optional student video. It does not tolerate retransmission delays, it must route through a media fabric close to users, and it fails in ways the control plane never sees.

A strong answer separates them immediately: signaling and application state flow through regional control services over WebSocket; RTP media flows through a Selective Forwarding Unit fabric that never touches your databases per packet. The bridge between the planes is narrow: join tokens, stream identifiers, and session events.

Why the problem is distinctive

A chat system can deliver a message five seconds late. A classroom cannot deliver a sentence five seconds late and still feel like teaching. Latency, ordering, and presence freshness define the product. At the same time, classrooms have structure chat lacks: roles with asymmetric permissions, one-to-many broadcast with a few promoted speakers, durable groups inside a session, and post-session artifacts such as attendance, recordings, and transcripts.

Interaction features are the differentiator this brief demands. Hand raise is a durable, ordered, visible queue, not a chat message. Breakout rooms are an atomic re-routing of media and chat membership. Teacher controls such as mute-all or spotlight are authoritative commands that must reach every participant quickly and reconcile with late joiners. Attendance requires joining presence with identity and policy, not counting sockets.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. Zoom reported more than 300 million daily meeting participants at its April 2020 peak and describes SFU-based video routing with simulcast. Discord's engineering blog has documented scaling an Elixir WebSocket gateway to 5 million concurrent users. Google reported billions of daily meeting minutes on Meet during 2020. Agora markets a software-defined real-time network for interactive streaming with hundreds of milliseconds latency targets. These are company-reported figures for context, not requirements for our system.

For capacity planning, this answer explicitly assumes a mature platform with 8 million daily active users, 5 million concurrent participants at scholastic peak, 167,000 concurrent classrooms of about 30 people, and 1.2 million class sessions per day, with a five-times burst factor for the first week of term. Unless tied to a citation, every number is a stated design assumption, budget, or target, not a claim about any company's private architecture.

The four architectural planes

1. Media plane: SFU forwarding, simulcast layers, congestion response, recording mixers, and regional media routing.
2. Signaling plane: WebSocket session channels, SDP and ICE coordination, spotlight and mute commands, join and leave events.
3. Application plane: class scheduling, roster and roles, chat and Q&A, hand raise, breakout orchestration, attendance, quizzes.
4. Artifact plane: recordings, transcripts, captions, whiteboard snapshots, attendance exports, moderation evidence.

Keep the planes separate. Let chat degrade without touching audio. Let attendance be eventually consistent while presence stays fresh. Let recordings fail open while live media fails safe. A classroom interview answer that treats these as one pipeline collapses under the first failure question.