Design a Lecture Capture & Replay Platform

Problem statement

Design a lecture capture and replay platform for a university-scale deployment. Room appliances and instructor laptops capture scheduled lectures, hybrid seminars, and exam-review sessions. The platform ingests the recordings, transcodes them into an adaptive delivery ladder, generates captions and transcripts, synchronizes uploaded slides with the video timeline, publishes the session into a course catalog with roster-scoped access, and lets students replay the lecture with aligned slides, searchable transcript, pinned Q&A, and instructor quiz checkpoints.

This is not object storage with a video player. The distinctive load comes from four properties. First, ingest is bursty and correlated: hundreds of rooms finish lectures at the same ten-minute boundaries, so encoding demand arrives in waves. Second, replay demand is inverted from ingest: it peaks in the evening and before exams, hours to days after capture. Third, the media is pedagogically structured: a timestamp inside a transcript, a slide, or a quiz is a first-class address that students link to, so every artifact must carry a stable media time reference. Fourth, access is roster-scoped and legally constrained: recordings contain student voices, faces, and sometimes disability accommodations, so authorization is per-course, per-section, and auditable.

Why this is not YouTube

A public video platform optimizes global discovery and viral tail distribution. A lecture platform optimizes guaranteed availability of a known catalog on a semester schedule, near-real-time turnaround between the end of a lecture and its replayability, deep-linking into media time, and institutional governance. Widely reported public figures put open video platforms at roughly five hundred hours of upload per minute; a university platform instead cares that a 9:00 lecture is watchable by 9:20 with captions. The design therefore separates four planes.

The four architectural planes

Capture plane: room schedulers, appliances, laptop agents, live encoding, chunked resumable upload, and upload integrity.
Processing plane: transcode ladder, ASR and captioning, slide synchronization, thumbnail and chapter extraction, content safety review for Q&A, and packaging into HLS/DASH.
Delivery plane: origin packaging, CDN distribution, ABR manifests, DRM or signed URLs, and player state.
Engagement plane: catalog, watch analytics, transcript search, Q&A alignment, quiz checkpoints, and instructor dashboards.

A strong answer keeps the planes independent. A transcode backlog must not block live viewing of an in-progress lecture. A search index rebuild must not delay playback. A caption correction must not require re-encoding the video.

Public operating baseline versus design assumptions

Commercial platforms demonstrate the category is real: Panopto publicly describes in-video search across slide decks and recordings, Kaltura publishes an open media platform used by universities and enterprises, and Echo360 describes classroom capture appliances with active-learning features. These are cited product descriptions, not our architecture. Every scale number used for capacity planning in this answer is an explicit design assumption for a fictional multi-campus deployment, labeled as such wherever it appears.

Key Highlights

•The platform is four planes: capture, processing, delivery, and engagement; each degrades independently.
•Ingest is correlated in waves at class-change boundaries; replay peaks hours later in the evening.
•Media time is a first-class address: transcripts, slides, Q&A, and quizzes all bind to stable timestamps.
•Access is roster-scoped and legally constrained, so authorization is per-course and auditable.
•Turnaround time from lecture end to replayable asset is the defining product SLO, not raw storage cost.