Building an Online Learning Platform: Live Classes, Exams, and Video Infrastructure
What's behind an online learning platform? The fundamentals of live classes, a video library, and a fair exam system.
4 min read
From the outside, an online learning platform looks simple: a list of videos, some lesson pages, a progress bar. The kind of thing you'd estimate at "three weeks, tops."
Then you run the first live class. Fifty students join at once, the instructor's audio starts stuttering, three video feeds freeze, somebody types "I can't hear the teacher," and within minutes the chat panel has spiraled into a stream of complaints. Then the first exam goes out. A student's browser closes mid-test, their timer resets, and nobody is sure what happens next.
An online learning platform is a product whose hidden surface is ten times bigger than its visible one. We learned that the hard way while building Tengra Akademi.
Three Systems Standing on Each Other's Shoulders
The Akademi platform runs three different systems in parallel. None of them is enough on its own; all three need to be solid.
1. Courses — The Skeleton
Courses, units, lessons, content. Where did a student start, where are they now, what have they finished, where did they get stuck? This sounds basic, but if you don't design it well the platform turns into "a hard drive that videos fall into." Building a flow where neither the instructor nor the student loses track is the spine of the product.
2. Exams — Where Surprises Live
"An exam module" sounds like one sentence. Once you start digging, it grows into a tangle: multiple choice or essay? partial credit? can students go back and change answers? what happens when the timer runs out? what if the network drops? do we shuffle? open book or not?
Most exam modules trip on the very first of these questions.
3. Live Classes — The Highest-Stakes Moment
If a recorded video breaks, you fix it tomorrow. If a live class breaks, it breaks in front of fifty students — and recovering reputation after that is hard, both for the instructor and the institution. Which is why our live infrastructure is the most ruthlessly tested part of the platform.
Video Library: "Just Make It Fast" Isn't Enough
Every uploaded video is automatically prepared in multiple qualities. When the student is on 4G, quality drops gracefully; on fiber, it climbs back up. All silently, without anyone clicking anything.
Cost Tip
Serving a single video quality looks simpler at first. Then your bandwidth bill starts hurting. Multi-quality streaming meaningfully lowers the bill and gives smoother playback — one of those rare architectural decisions where both sides win.
Videos are served from a distributed network: students in Turkey load from servers in Turkey, students in Germany load from servers in Germany. The result: a player that starts in the first second and doesn't stall in the middle.
Live Class: Talking to 50 People at Once
A typical video-call tool is built for 5–10 person meetings. At 50 students, everything starts creaking — especially on the student side. The classic complaint, "the teacher's machine is fine but my laptop melted," isn't a student problem; it's an architecture problem.
Our solution is to collect the instructor's stream at a central point, prepare it there, and distribute optimized streams out to the students. The student's device doesn't need to decode 50 separate streams; it gets one, tuned for it. A regular laptop can comfortably attend a 50-person session.
Recording is automatic. Shortly after class, the recording lands in the library; students who missed it — or just want to review — can replay it with one click.
Designing a Fair Exam: Think Before They Try to Cheat
Two ground rules sit underneath everything else in our exam module:
- Question shuffling. Every student sees questions and options in a different order. Even students sitting next to each other aren't really taking the same exam.
- Server-side timing. The countdown lives on our servers, not the student's browser. If the browser closes, the connection drops, the laptop reboots — the timer keeps going. When the student returns they pick up where they left off, with no "extra time" gained.
A note from the trenches
"Keep the exam timer in the browser, it'll be faster" — this is the single most common mistake we see in exam modules. The first student who wants to cheat will simply pull the network cable and reset the timer. Server-side timing is non-negotiable.
On top of that, we issue digital certificates. When a student passes, they automatically get a signed certificate with a verification link. An employer who receives that certificate can answer "is this real?" with one click — and the practical value of this turned out to be much bigger than we initially expected.
The Instructor Side: Don't Build Things They Won't Use
The best thing we did while building this software was sitting next to instructors and watching them work. We avoided adding features they didn't need; and we never skipped the small things they did need.
A few examples:
- Quick attendance. Who's actively engaged in the live class, who's idle — the instructor sees it at a glance.
- One-click polls. "Did everyone follow that?" can be turned into a quick yes/no without breaking the flow.
- Auto-summary after class. The system drafts rough notes from the recording; the instructor edits and shares them with students.
None of this is "wow, what technology" stuff. But instructors use it every day — which, long term, is the part that matters.
Wrapping Up
An online learning platform isn't "e-commerce for courses." An e-commerce mistake costs you an order; a learning-platform mistake risks an exam, a class, sometimes a student's certificate. So "good" isn't enough on either the infrastructure side or the product side — it has to be resilient.
The good news: once it's built right, the system stands on its own. Instructors teach, students learn, and we sit in the back row, quietly watching it run.
For more details, take a look at the Tengra Akademi page.
