Scaling Live Classes and Video for Thousands of Students

Live classes for thousands of students do not scale as peer-to-peer video. The fix is to match the architecture to the lesson: run small interactive seminars through a selective forwarding server, deliver large lectures as a one-to-many broadcast stream, and treat recordings and chat as separate scaling problems. For the hard part, real-time media transport, lean on a specialist vendor rather than building it from scratch.

If you would rather have the live-class layer built and integrated for you, see how RAITHub would build it below.

This post is for EdTech founders and engineers adding or scaling live video in a learning product. It is engineering guidance. RAITHub's education build is PadhAI, an AI tutoring platform; RAITHub has not shipped a standalone live-video product, and the real-time media transport below is work most teams should buy, not build.

Why does my live class fall apart past a few students?

Because full-mesh video, where every participant sends their stream directly to every other participant, grows with the square of the room. Each extra student adds a connection to everyone else. The Web's real-time API, WebRTC, connects browsers "to transfer arbitrary data and/or media streams" directly (MDN: WebRTC API), which is excellent for one-to-one and small groups and unworkable for a class of thirty, let alone a thousand. The uplink on a student's connection cannot send twenty-nine copies of their camera.

Topology	How media flows	Scales to
Full mesh (peer-to-peer)	Everyone sends to everyone	A handful of people; grows with the square of the room
SFU (selective forwarding unit)	Everyone sends once to a server, which forwards streams	Interactive rooms of tens, with effort more
Broadcast / streaming	One source, encoded once, delivered to many viewers	Thousands of viewers; near-live, not two-way

Interactive or broadcast: which does this lesson need?

Decide per lesson type, because they have different costs and different limits. Most platforms need both, and the mistake is forcing one pattern onto every class.

• Interactive seminar (a tutor and a small group who all speak and share): use an SFU. Each person uploads one stream; the server forwards what each viewer needs. This is where two-way teaching happens, and it is the expensive mode, so cap room sizes deliberately.
• Large lecture or webinar (one teacher, many watchers): broadcast. The teacher's stream is encoded once and delivered to thousands as near-live video, with questions arriving through chat, not open mics. Students watch with a few seconds of delay, which is fine for a lecture.
• Hybrid (a lecture that promotes a student to "on stage"): run a small SFU room for the active speakers and broadcast that out to everyone else, moving a student between the two when they are called on.

The arithmetic makes the choice obvious. A 1,000-student interactive room is 1,000 uploads and a forwarding fan-out no small team should run; the same 1,000 students as a broadcast is one upload and a delivery problem that content delivery networks already solve.

Should I build the video layer or buy it?

Buy the real-time media transport, and build the teaching product around it. Running your own global, low-latency media servers is a specialist, around-the-clock operation. Build-vs-buy by component:

Component	Build or buy	Why
Real-time media transport (SFU, TURN, global routing)	Buy	Hard, operationally heavy, and a solved problem vendors run at scale
Broadcast delivery	Buy (a streaming or CDN service)	Encoding and global delivery are commodity infrastructure
Classroom product (rooms, roles, schedule, attendance)	Build	This is your product; it is where you differentiate
Recording storage and playback	Build around a vendor's recording output	Storage and access control are yours; capture is theirs
Chat, hand-raising, polls	Build	Tied to your data model, roles and moderation

Open-source media servers exist, and a specialist team can run them, but for most EdTech products a hosted media vendor plus your own classroom product is the faster, safer route. The same build-vs-buy logic applies to the rest of the stack; the honest trade-offs for LMS features are in white-label LMS vs building your own.

How should recordings, chat and attendance scale?

Each is its own problem, and each spikes at a different moment. Design them separately rather than bolting them onto the video.

• Recordings are a storage and access-control problem. Capture through your media vendor, store the file in your own cloud, and gate playback by enrolment and role. A popular recording released after class is a download spike; serve it from a CDN, not your app server.
• Chat at scale is a fan-out problem. A thousand students in one lecture chat is a lot of messages to deliver. Rate-limit per student, and consider a dedicated real-time messaging service rather than your main database. The limits-and-abuse patterns are in rate limiting without Redis on serverless.
• Attendance and join events spike at the start. A thousand students joining in two minutes is the same correlated-load problem as an exam start, covered in surviving the exam-season concurrency spike. Record a join as a cheap event; compute attendance reports afterwards.

What breaks live classes on real student connections?

The classroom works on your office wifi and fails on a student's mobile data. Plan for the real conditions.

Condition	What it breaks	What helps
Weak or mobile connection	Frozen video, dropped audio	Adaptive quality; audio-first fallback; a vendor with good routing
Restrictive networks (school, corporate)	Media cannot connect at all	A TURN relay, which hosted vendors provide
Cheap or old devices	CPU overload, crashes	Limit incoming streams; broadcast mode for large classes
Everyone joins at once	Signalling and join endpoints overload	A lobby; cheap join events; stagger where you can

How long does it take to add live classes yourself?

Integrating a hosted media vendor for small interactive rooms, with rooms, roles and a schedule in your product, is typically a few weeks of focused work. Adding broadcast mode, recordings with access control, and scaled chat is more. Building your own media servers is a different order of effort and ongoing operation, and is rarely the right call for an EdTech team. The main risk of doing it yourself is underestimating the transport layer and shipping something that works in a demo and fails on a classroom of real connections, so test on throttled networks and cheap devices before a live cohort.

How RAITHub would build this

Scope:

• A classroom product around a hosted media vendor: scheduled rooms, teacher and student roles, a lobby, and attendance as cheap join events.
• Interactive SFU rooms for seminars and broadcast delivery for large lectures, with a path to promote a student "on stage".
• Recordings stored in your own cloud, gated by enrolment, and served through a CDN.
• Scaled chat and hand-raising with per-student rate limits and moderation hooks.
• A load test shaped like your largest class start and recording-release spike.

Timeline: integrating live video into an existing product is backend-heavy work in the 6–12 week backend and API range; a new learning platform with live classes follows the SaaS development path. You receive: automated tests and CI, handover docs and a class-day runbook, and full IP under an NDA signed before detailed discussion. Student data and recordings stay in your own cloud account; development uses synthetic data. Next step: a free 15-minute technical audit, then a written fixed quote; RAITHub publishes no rates. See what RAITHub builds for education on the EdTech industry page, and book the free audit with your largest class size and your mix of seminars and lectures.

Frequently asked questions

Why does my live class break with more than a few students?

Because peer-to-peer (mesh) video makes every participant send to every other, so load grows with the square of the room and each student's uplink cannot send that many copies. Route media through a selective forwarding server for interactive rooms, and use broadcast delivery for large lectures.

What is an SFU, and when do I need one?

A selective forwarding unit is a server that each participant uploads one stream to, and which forwards the streams each viewer needs. You need one for interactive rooms of more than a few people, where everyone can speak and share. For one-to-many lectures, use broadcast streaming instead.

Should I build my own video infrastructure?

Usually no. Real-time media transport, including SFU, relays and global routing, is a specialist, around-the-clock operation. Buy that from a hosted media vendor and build your teaching product (rooms, roles, schedule, recordings, chat) around it, which is where you actually differentiate.

How do I handle a class of a thousand students?

Deliver it as a broadcast: the teacher's stream is encoded once and delivered to many viewers near-live through a CDN, with questions through chat rather than open mics. Reserve interactive, two-way rooms for small seminars, and promote a student "on stage" only when needed.

How do recordings scale?

Capture through your media vendor, store the file in your own cloud, gate playback by enrolment and role, and serve it through a CDN so a post-class download rush does not hit your app server. Treat recording storage and access as a separate problem from live delivery.

Why does video work in testing but fail for real students?

Because real students are on weak mobile connections, restrictive school networks and cheap devices. Use adaptive quality, an audio-first fallback, and a vendor that provides TURN relays for restrictive networks, and test on throttled connections and low-end devices before a live cohort.