ODL Video Service — Architecture & Data Flows
Generated 2026-06-24 17:02 UTC · c4gen dev
ODL Video Service (OVS) is MIT Open Learning's video hosting and lecture-capture platform. A Django/DRF backend with a React 15 frontend ingests source video (Dropbox Chooser uploads or an S3 watch-bucket drop), transcodes it to HLS + MP4 via AWS MediaConvert, and delivers private content through CloudFront signed URLs. Keycloak (federating MIT Touchstone SAML) provides OIDC auth; access control is enforced through KeycloakGroup membership (formerly MoiraLists). Celery + RedBeat run async upload/transcode/YouTube/janitor tasks. Public videos and their transcripts are exposed via a REST API that MIT Learn's ETL ingests daily, and video metadata is pushed to Open edX (edxval) for course playback.
This is a C4 view of ODL Video Service within the MIT Open Learning SOA, focused on how data is created and propagated — synchronous request paths and asynchronous (queued, scheduled, event-driven) flows alike. Use it for onboarding and as a holistic reference when realigning flows or hunting harmful cycles and fragile linkages.
How to read these diagrams
These are C4 model diagrams (C4-PlantUML). Read them top-down: System Context (the whole SOA) → Container (one system's runtime units) → Dynamic (a single data flow, step by step).
- People are rounded boxes; systems and containers are rectangles; databases and queues have distinct shapes.
- Each arrow is a data flow labelled with what moves.
- Solid arrows are synchronous (request/response, caller blocks).
- Amber dashed arrows are asynchronous (queued, scheduled, or event-driven — caller does not block).
- Drag to pan, scroll to zoom. Boxes with a link drill into the next level.
Contents
- System Context — ODL Video Service and the systems it exchanges data with.
- Containers — the runtime units inside ODL Video Service.
- Data Flows — key interactions, step by step (sync & async).
- Dependencies & Cycles — graph-derived coupling, cycles, fragile links.
Keeping this current
These pages are generated from a structured model by
architecture_maps/c4gen. The cross-service edges are extracted deterministically
from the witan-code graph; node prose and scenarios are curated. See
the generator README
to regenerate after the system changes.