How to scale a video learning platform

To scale a video learning platform, treat recorded lectures, live classes, tests and the core app as separate workloads: send video bytes through a CDN, run transcoding through a queue, choose live-streaming technology by the latency you need, and design tests for the peak minute. Scaling video isn't like scaling an ordinary website, because most of the load is bytes of video rather than page requests, and the spikes are unusually sharp.

A platform can run happily for a few hundred students and then buckle at a few thousand, usually on the evening that matters most, when a popular teacher goes live or a test series opens. Here's how the pieces fit together, from upload to playback.

Four workloads, four different problems

1. Recorded lectures: huge volumes of data, but predictable and easy to cache.
   
   
2. Live classes: real-time video to many students at once, with chat and polls on top.
   
   
3. Tests and quizzes: tiny amounts of data, but thousands of students acting in the same minute.
   
   
4. Everything else: logins, payments, dashboards, doubt forums and notifications.
   
   

Each needs a different design, and the first rule of scaling is isolation: a spike in one shouldn't take down the others. A packed live class should never stop students from paying fees or submitting a test.

The recorded-video pipeline

1. Upload straight to object storage using resumable uploads, rather than pushing large files through your application servers.
   
   
2. Transcode each lecture into several versions, called an adaptive bitrate (ABR) ladder, such as 240p, 360p, 480p, 720p and 1080p. H.264 plays almost everywhere; newer codecs such as HEVC and AV1 give smaller files at the same quality, but device support varies.
   
   
3. Package: split the video into short segments in HLS or DASH format, and encrypt them.
   
   
4. Store the output in object storage, and move rarely watched originals to cheaper storage tiers.
   
   
5. Deliver through a CDN, using signed, expiring URLs or tokens.
   
   
6. Play in an adaptive player that switches quality as the student's connection changes.
   
   

Transcoding is a batch job, so treat it like one: a job queue, a pool of workers that grows and shrinks with the queue (or a managed transcoding service), priorities so today's lecture jumps ahead of a back-catalogue re-encode, and jobs that can be retried safely. Our guide to video transcoding pipelines walks through each stage.

Tune the ladder for lectures and for Indian networks

A lecture is mostly a teacher, a board or slides, and a voice. There's far less motion than in a cricket match, so lectures compress well, and you can usually use lower bitrates than a film service would for the same perceived quality. What matters more is legibility. Can a student read the handwriting on the board at 360p? Test every rung of the ladder with real lectures.

Plan for the students you actually have. Many watch on budget Android phones over mobile data, and connections in smaller towns can be patchy. Keep low rungs such as 240p and 360p, consider an audio-only option, and offer in-app downloads, still encrypted, so students can save lectures over hostel Wi-Fi and watch them later. Content-aware encoding, which picks bitrates for each video instead of using one fixed ladder, can save a lot of bandwidth.

Let the CDN do the heavy lifting

Some quick arithmetic shows why. Suppose 10,000 students are watching at once at an average of 1.5 Mbps. That's 15 Gbps of sustained traffic, far more than a single origin server should ever handle. Over a month, a student who watches two hours a day at 1 Mbps uses about 0.9 GB a day, so 10,000 such students add up to roughly 270 TB. These are illustrative figures, so plug in your own, but the shape never changes: video delivery is both your biggest bandwidth bill and your biggest scaling load.

A content delivery network (CDN) caches video segments on servers close to students, so your origin serves each segment once instead of thousands of times. To get the most out of it:

• Aim for a high cache-hit ratio, and make sure access tokens don't give every student a different cache key for the same segment.
  
  
• Put an origin shield, a mid-tier cache, between the CDN's edge servers and your storage.
  
  
• Consider a second CDN for big days, so one provider's bad hour doesn't become yours.
  
  
• Track performance by region and internet provider, not just the national average.
  
  

Live classes: choose your latency deliberately

The right technology depends on how much delay a class can tolerate; our comparison of WebRTC and HLS for live classes goes deeper.

A typical live pipeline runs from the teacher's encoder to an ingest server (over RTMP or SRT), then a live transcoder, a packager and the CDN, while a recording is saved in parallel so the replay is ready soon after class. To make it hold up:

• send a backup stream from the studio to a second ingest point;
  
  
• run chat as a separate system with its own scaling, and add slow mode or rate limits for very large classes;
  
  
• pre-warm capacity before big sessions, and do a dry run before any major launch.
  
  

Tests: design for the synchronised spike

Imagine a mock test that opens at 10 a.m. for 20,000 students. Most of them press "Start" within the same minute, and most submit in the final few minutes. Average traffic tells you nothing here; the peak is everything. Our guide to conducting an online exam covers the academic side of the same day.

• Prepare question papers in advance and serve them from a cache, instead of assembling each one from the database on request.
  
  
• Save answers on the device and sync them in the background, so a slow network never loses work.
  
  
• Accept submissions into a queue, and calculate scores, ranks and analytics afterwards.
  
  
• Make submission idempotent, so a double tap or an automatic retry can't create duplicates.
  
  
• When things slow down, show honest messages such as "Your answers are saved" instead of errors.
  
  

Keep the application layer stateless

Behind the video sits an ordinary web application, and it should scale horizontally: stateless servers behind a load balancer, sessions in a shared store such as Redis, background queues for emails, SMS and WhatsApp notifications, and a database shielded by caching, read replicas and connection pooling. Our guide to handling 100,000 concurrent users covers these techniques in detail.

Measure what students actually feel

Server CPU tells you little about whether a lecture played well. Collect quality-of-experience data from the player itself: time to first frame, how often playback stalls to buffer, the average quality delivered and the rate of playback failures, broken down by device, city and internet provider. Pair these with server metrics such as error rates and 95th-percentile response times, and set alerts that fire before a big session goes wrong, not after complaints arrive. Our explainer on monitoring vs observability covers the tooling.

Keep costs in check as you grow

• Bandwidth dominates video costs, so right-size your ladder and use efficient codecs on the devices that support them.
  
  
• Agree a retention policy for original files and rarely used renditions.
  
  
• Move old batches that are still on sale but rarely watched to cheaper storage tiers.
  
  
• Revisit CDN pricing once your traffic is predictable; committed volumes usually cost less.
  
  

Key takeaways

• Treat recorded video, live classes, tests and the core app as separate workloads, and isolate them from each other.
  
  
• Build an asynchronous pipeline: upload to storage, transcode through a queue, package, protect and deliver through a CDN.
  
  
• Tune bitrate ladders for lecture content and for the networks and phones your students really use.
  
  
• Choose live-streaming technology by the latency you actually need.
  
  
• Design tests for the peak minute, and measure playback quality from the student's side.
  
  

Scaling a video learning platform is less about one clever trick than about sensible separation: heavy bytes to the CDN, slow work to queues, spikes absorbed by caches and pre-built content, and constant measurement from the student's point of view. Get those foundations right, and growing from 500 students to 50,000 becomes a matter of capacity planning rather than crisis management.

Frequently asked questions

How much bandwidth does a video learning platform need?

Multiply concurrent viewers by the average bitrate they watch at. As a worked example, 10,000 students watching at 1.5 Mbps need about 15 Gbps of sustained delivery, far more than any single origin server should handle. That is why video is served from a CDN, and why a well-tuned bitrate ladder has such a large effect on both cost and reliability.

Should live classes use WebRTC or HLS?

It depends on the delay you can accept. WebRTC gives sub-second latency for small, interactive sessions such as doubt-clearing and mentoring, but it is harder and costlier to scale. Low-latency HLS or DASH suits large live lectures with chat and polls, at a few seconds' delay, and standard HLS is the cheapest and most robust option for very large broadcasts.

What is a bitrate ladder?

A bitrate ladder is the set of versions each video is encoded into, such as 240p, 360p, 480p, 720p and 1080p, each at its own bitrate. The player switches between these rungs as a student's connection changes, so playback continues instead of stalling. For lectures, test each rung to make sure handwriting on the board is still legible.

How do you handle thousands of students starting a test at once?

Design for the peak minute, not the average. Prepare question papers in advance and serve them from a cache, save answers on the device and sync them in the background, accept submissions into a queue and calculate scores afterwards, and make submission safe to retry. Load test the whole journey at full scale before the real test day.