The design question
A virtual-classroom product often has two different user needs: some people must participate in a lesson immediately, while others only need to watch material after the session. Treating those needs as the same delivery problem creates avoidable confusion.
This article explains an architecture pattern for separating those paths. It is not a published capacity benchmark or a cost study. The goal is to make the product boundary explicit: live, bidirectional participation belongs on the real-time path; playback made available later belongs on the delayed path.
Live interaction: WebRTC
WebRTC is suited to the part of a classroom where timing and two-way communication matter: teachers, moderators, and learners who must speak, see changes, or react during the current session. A media server such as LiveKit can provide the real-time media layer, while the application keeps authorization, room policy, and product state outside the media plane.
The important question is not simply how many connections exist. It is which users need immediate participation, which media they receive, and what product behavior is required when a participant changes role.
Playback later: HLS
HLS is useful when the product requirement is recorded or processed material available after the session. It is a delivery path for delayed playback, not a substitute for a participant who needs to join the class now.
Keeping that distinction visible prevents a common architecture mistake: describing HLS as a live fallback without defining the latency, interaction, and audience consequences. A user who needs real-time, bidirectional media has a different requirement from a user who can return later to watch a recording.
Keep media and signaling separate
Media routing and application signaling are related but different concerns. A practical design keeps room state, permissions, presence, moderation actions, and product events in an application-control layer rather than assuming the media transport should own every state transition.
For event-driven coordination, a durable messaging layer such as NATS JetStream can help services exchange state changes while preserving explicit ownership boundaries. The precise topology depends on the product, but the principle is stable: use the media layer for media and keep business events observable and independently recoverable.
Role changes should be product events
A learner becoming an active participant is more than a transport change. It can involve authorization, room policy, UI state, moderation, and auditability. Model that promotion as an application event with an explicit outcome, then update the relevant media permissions.
This makes failures easier to reason about: the system can distinguish an authorization decision from a media-connection failure, and it can surface an accurate state to the user.
Architecture review checklist
Before choosing protocols or sizing infrastructure, answer these questions:
- Which roles require immediate two-way interaction?
- Which users can consume delayed playback instead?
- What latency is acceptable for each path?
- Where do permissions, room state, and moderation events live?
- How is a role promotion authorized, observed, and recovered if a downstream action fails?
- Which measurements are genuinely available before making performance or cost claims?
A clear answer to those questions is more useful than a headline capacity number. It gives engineering and product teams a shared vocabulary for deciding where WebRTC is necessary and where delayed playback is the correct experience.
Related case study
This design guide is a general decision framework, separate from the HonarAmoozesh implementation. For a bounded account of the platform architecture that supported 5,000 concurrent users, including live WebRTC participation and HLS playback made available hours after a session, read WebRTC Live Streaming and Delayed HLS Playback for 5,000 Concurrent Users.