E-Learning-Plattform-Architektur: Mandantenfähige Kurse, Fortschrittstracking und Video-Auslieferung
Die meisten Lernplattformen scheitern nicht am schlechten Videoplayer. Sie scheitern an Entscheidungen aus dem ersten Monat: wie Kursinhalte versioniert werden, wie Mandanten getrennt sind und wohin Fortschritts-Events geschrieben werden. Diese Entscheidungen kosten am Anfang fast nichts, wenn man sie richtig trifft. Sie später zu korrigieren, wenn zehn Institutionen und fünfzigtausend Lernende vom System abhängen, bedeutet ein Migrationsprojekt mit echtem Downtime-Risiko.
Dieser Beitrag behandelt die vier Architekturprobleme, die uns am häufigsten begegnen, wenn EdTech-Teams mit ihrer Plattform zu uns kommen: Kursversionierung, Mandantentrennung, Fortschrittstracking unter Schreiblast und Video-Auslieferung. Am Ende stehen der Stack, den wir für europäisches EdTech-SaaS empfehlen, und die Compliance-Regeln, die du nicht aufschieben kannst. Wenn du noch entscheidest, welche Features überhaupt in dein Produkt gehören, starte mit unserem Beitrag über unverzichtbare Features in Bildungssoftware und komm für das Datenmodell hierher zurück.
Kursversionierung: Lernende stecken mitten im Kurs, während du editierst
Hier ist das Szenario, an dem naive Kursmodelle brechen. Ein Dozent aktualisiert Modul 3 eines Kurses mit zehn Modulen. Vierhundert Lernende stecken irgendwo in diesem Kurs. Sechzig davon haben das alte Quiz in Modul 3 bereits bestanden. Was bedeutet ihr Fortschritt jetzt?
Wenn deine lessons-Tabelle eine Zeile pro Lektion hat und der Dozent diese Zeile direkt editiert, hast du stillschweigend die Geschichte umgeschrieben. Zertifikate vom letzten Monat zeigen jetzt auf Inhalte, die nicht mehr existieren. Einer Lernenden, die ein nicht bestandenes Quiz anficht, kannst du die Fragen nicht mehr zeigen, die sie tatsächlich beantwortet hat.
Das Muster, das funktioniert, ist Snapshot-basierte Versionierung. Ein Kurs hat einen veränderbaren Entwurf und unveränderliche veröffentlichte Versionen. Beim Veröffentlichen entsteht eine neue Versionszeile, und die Modul- und Lektionsstruktur wird tief kopiert (oder content-addressiert). Enrollments pinnen sich auf eine Version. Fortschrittsdatensätze referenzieren die gepinnte Version, nie den Entwurf.
Daraus folgen zwei praktische Regeln:
- Neue Enrollments bekommen immer die neueste veröffentlichte Version. Bestehende Enrollments behalten standardmäßig ihre gepinnte Version, mit einem expliziten Migrationspfad, wenn die Änderung ein Tippfehler-Fix ist und keine Umstrukturierung.
- Speichere eine Diff-Zusammenfassung zwischen Versionen. Wenn eine Institution fragt, warum Kohorte A und Kohorte B unterschiedliche Inhalte gesehen haben, willst du eine Antwort in Minuten und kein Archäologieprojekt.
Der Speicher-Overhead ist kleiner, als Teams befürchten. Kursstruktur ist winzig im Vergleich zu Video. Ein paar hundert Zeilen pro Veröffentlichung zu kopieren ist nichts; den Audit-Trail zu verlieren ist teuer.
Mandantentrennung zwischen Institutionen
Die meisten EdTech-SaaS-Plattformen bedienen viele Institutionen aus gemeinsamer Infrastruktur. Eine Universität, eine betriebliche Weiterbildungsabteilung und eine Zertifizierungsstelle leben alle in derselben Datenbank. Die Frage ist, wie hart die Wände zwischen ihnen sind.
Über die generellen Trade-offs haben wir im Rahmen unserer Arbeit an SaaS-Architektur schon geschrieben, und für E-Learning lautet die Kurzfassung: Ein gemeinsames Schema mit Tenant-Diskriminator-Spalte reicht für die meisten Plattformen, aber nur, wenn du es unterhalb der Anwendungsschicht durchsetzt. Row-Level-Security-Policies in PostgreSQL, verankert an der Tenant-ID, fangen die Query ab, die jemand zu scopen vergessen hat. In einer Symfony-Anwendung gibt dir ein Doctrine-Filter, der die Tenant-Bedingung an jede Query anhängt, dieselbe Garantie eine Ebene höher. Nutze beides. Die Kosten sind Minuten an Konfiguration; die Alternative ist, einer Universität zu erklären, warum eine andere Institution ihre Studierendenliste gesehen hat.
Manche Verträge erzwingen ein stärkeres Modell. Öffentliche Institutionen in Deutschland verlangen regelmäßig, dass ihre Daten auf Anfrage separierbar sind, was dich zu Schema-pro-Tenant oder mindestens zu tenant-partitionierten Tabellen mit sauberen Exportpfaden drängt. Entscheide das, bevor du den Vertrag unterschreibst, denn Schema-pro-Tenant nachträglich auf eine Shared-Schema-Plattform zu setzen ist eine der schmerzhafteren Migrationen, für die wir gerufen werden.
Identität verdient dieselbe Sorgfalt. Lernende existieren oft in mehreren Tenants: Eine Person kann an einer Institution Studentin sein und an einer anderen Kursautorin. Modelliere die Person einmal und die Tenant-Mitgliedschaft als separate Relation mit eigenen Rollen. Plattformen, die den User pro Tenant duplizieren, enden mit Passwort-Reset-Chaos und DSGVO-Löschanfragen, die die Hälfte der Datensätze verfehlen.
Fortschrittstracking ohne Schreib-Flaschenhals
Fortschrittstracking ist die Stelle, an der E-Learning-Plattformen leise umkippen. Die Granularität, die das Produktteam will, ist hoch: Videoposition alle paar Sekunden, jeder Quiz-Versuch, jede interaktive Übung. Multipliziere das mit gleichzeitigen Lernenden, und du bekommst eine Schreiblast, die alles andere auf der Plattform in den Schatten stellt. Eine mittelgroße Plattform mit 5.000 gleichzeitigen Video-Zuschauern, die alle 10 Sekunden ein Positions-Event senden, erzeugt 500 Writes pro Sekunde auf dieser einen Tabelle, den ganzen Tag.
Jedes Event direkt in eine normalisierte progress-Zeile in deiner Hauptdatenbank zu schreiben ist der Fehler. In der Demo funktioniert es, dann kommen Lock Contention und Index Bloat mit dem ersten großen Kunden.
Die Form, die hält, ist eine Trennung zwischen Event-Stream und materialisiertem Zustand:
| Schicht | Was sie speichert | Wo |
|---|---|---|
| Event-Log | Rohevents: Video-Heartbeat, Quiz-Versuch, abgeschlossene Übung | Append-only-Tabelle oder Queue, gebatchte Writes |
| Materialisierter Zustand | Aktuelle Position, Abschlussquote, bester Quiz-Score | Kleine Zeile pro Enrollment, asynchron aktualisiert |
| Reporting | Aggregate pro Kohorte, Kurs, Tenant | Nach Zeitplan aus dem Event-Log neu aufgebaut |
Video-Heartbeats brauchen keine Durability-Garantien. Puffere sie clientseitig, sende sie in Batches von 10 bis 30 Sekunden und behandle den Verlust eines Batches als akzeptabel. Quiz-Versuche sind das Gegenteil: In manchen Kontexten sind das rechtlich relevante Aufzeichnungen, also gehen sie über den durablen Pfad, mit Idempotency-Keys, damit ein wiederholter Request nicht zwei Versuche aufzeichnet.
Die Tabelle mit dem materialisierten Zustand bleibt klein und heiß, was das Dashboard der Lernenden schnell hält. Das Event-Log gibt dir Replay: Wenn das Produktteam nächstes Quartal eine neue Metrik will, baust du sie aus der Historie neu auf, statt eine Tracking-Änderung auszuliefern und drei Monate auf Daten zu warten.
Video-Auslieferung: CDN, signierte URLs und HLS
Liefere Kursvideos nie von deinen Applikationsservern aus, und auch nie aus einem öffentlichen Bucket. Bezahlte Kursinhalte hinter einer öffentlichen URL werden innerhalb von Wochen abgegriffen.
Die Standard-Pipeline sieht so aus. Dozenten laden über einen progressiven, wiederaufnehmbaren Upload hoch (tus oder S3 Multipart), damit eine 4-GB-Aufnahme über Hotel-WLAN eine Unterbrechung überlebt. Ein Transcoding-Schritt konvertiert die Quelle in HLS-Renditions mit mehreren Bitraten, erzeugt Thumbnails und produziert Untertitel-Dateien. Das Ergebnis landet in Object Storage hinter einem CDN.
Die Zugriffskontrolle lebt in signierten URLs. Die Anwendung prüft das Enrollment und stellt dann eine kurzlebige signierte URL aus (oder ein signiertes Cookie für HLS, da eine Playlist viele Segmentdateien referenziert), gebunden an genau diese Lernende. Eine Gültigkeit von wenigen Stunden balanciert Sicherheit gegen Wiedergabeunterbrechungen. Das CDN validiert die Signatur, deine Server fassen also nie Videobytes an.
Adaptive Bitrate zählt in der Bildung mehr als in der Unterhaltung. Gelernt wird im Campus-Netz, im Zug, auf alten Laptops. Eine 240p-Rendition, die weiterläuft, schlägt einen 1080p-Stream, der buffert. Untertitel sind ebenfalls nicht optional, sowohl wegen der Gesetzgebung zur Barrierefreiheit als auch, weil ein erheblicher Teil der Lernenden ohne Ton schaut.
Generiere Untertitel automatisch in der Pipeline, aber gib Dozenten einen Bearbeitungsdurchgang. Automatische Transkription von Fachvokabular ist immer noch holprig, und ein Chemiekurs mit verstümmelten Formelnamen in den Untertiteln wirkt nachlässig.
Zertifikate und manipulationssichere Audit-Trails
Ein Zertifikat ist die Behauptung, dass eine bestimmte Person eine bestimmte Kursversion mit einem bestimmten Ergebnis an einem bestimmten Datum abgeschlossen hat. Jede dieser Referenzen muss unveränderlich sein, weshalb Zertifikate von der Versionierungsentscheidung aus dem ersten Abschnitt abhängen.
Speichere das Zertifikat als signierten Datensatz: ein Hash der Zertifikats-Payload, signiert mit einem Plattform-Key, verifizierbar über eine öffentliche URL. Wenn ein Arbeitgeber ein Zertifikat drei Jahre später prüft, sollte die Verifikation nicht davon abhängen, dass deine relationale Datenbank die Originalzeilen noch im Originalzustand enthält. Die Zertifikatsausstellung per Hash-Chain in ein Append-only-Log zu schreiben ist eine günstige Versicherung für den Tag, an dem ein Streitfall oder ein Akkreditierungsaudit ansteht.
Compliance prägt vom ersten Tag an, wie du eine E-Learning-Plattform entwickelst
Drei Regelwerke zählen für die meisten unserer Kunden. Die DSGVO gilt für alle Lernenden in der EU: Recht auf Löschung, Datenminimierung und eine klare Antwort darauf, wohin Video-Analytics-Daten fließen (was deine Wahl von CDN und Transcoding-Anbieter beeinflusst). FERPA gilt, wenn US-Bildungseinrichtungen deine Kunden sind; es beschränkt, wer Studierendendaten sehen darf, und erzwingt eine Rollentrennung, die dein Berechtigungsmodell ausdrücken können muss. Barrierefreiheit heißt WCAG 2.1 AA über die gesamte UI plus Untertitel auf allen Videos, und in der EU hat der European Accessibility Act das seit 2025 zur Vertragsrealität gemacht statt zu einem Nice-to-have.
Nichts davon lässt sich sauber nachrüsten. Löschung ist einfach, wenn Identität einmal modelliert ist, und schmerzhaft, wenn Zeilen von Lernenden pro Tenant dupliziert sind. Untertitel sind einfach, wenn die Transcoding-Pipeline sie erzeugt, und schmerzhaft, wenn dreitausend Videos ohne sie existieren.
Ein Stack, der für europäisches EdTech-SaaS funktioniert
Für Kunden, die in Europa bauen, landen wir meist bei: Symfony mit API Platform für das Backend, PostgreSQL mit Row-Level Security für die Mandantentrennung, Redis plus eine Message Queue (Symfony Messenger mit RabbitMQ oder SQS) für die Event-Pipeline, Next.js für das Frontend der Lernenden und ein Object Store in einer EU-Region mit einem CDN, das signierte Cookies für Video unterstützt. Transcoding über einen Managed Service statt selbst gehosteter FFmpeg-Farmen, außer Videovolumen ist dein zentraler Kostentreiber.
Dieser Stack ist mit Absicht langweilig. E-Learning-Plattformen leben und sterben mit Datenintegrität und Zuverlässigkeit der Auslieferung, und jede Komponente oben hat ein Jahrzehnt Produktionsgeschichte hinter sich. Wenn du eine zweite Meinung zu deinen eigenen Entscheidungen willst, dafür gibt es unsere Engagements zur Tech-Stack-Strategie, und wenn die Plattform schon existiert und knarzt, findet ein Code- und Architektur-Review die tragenden Probleme, bevor dein größter Kunde sie findet.
Du baust oder rettest gerade eine E-Learning-Plattform? Wir unterstützen EdTech-Teams mit Webanwendungsentwicklung und genau dieser Art von Architekturarbeit. Schreib an hello@wolf-tech.io oder schau dich auf wolf-tech.io um, um zu sehen, wie wir arbeiten.