Von Bare-Metal-Basteln zu elastischer Video-Infrastruktur: Wie ayedo Streambase für große Live-Events skalierbar gemacht hat

Video ist die Königsdisziplin der Infrastruktur.

Während viele SaaS-Anwendungen relativ gutmütig sind, reagiert Video gnadenlos: Ein kleiner Konfigurationsfehler wird sofort als Ruckeln sichtbar. Eine CPU-Spitze erzeugt Audio-Aussetzer. Eine unvorhersehbare Lastwelle führt nicht zu „etwas langsamer", sondern zu einem abgebrochenen Stream – live, vor Publikum.

Streambase Media betreibt eine Video-Plattform für Unternehmen: Live-Streaming von Firmenevents, hybride Meetings und eine On-Demand-Bibliothek in einer Lösung – als europäische Alternative zu Zoom Events und Vimeo Enterprise. Rund 120 Firmenkunden nutzen die Plattform, von Town-Halls mit 50 Teilnehmern bis zu Produkt-Launches mit mehreren tausend Zuschauern.

Das Produkt war am Markt. Der Betrieb war das Problem.

Ausgangslage: Funktionierende Architektur – aber nur, solange die Last vorhersehbar ist

Streambase setzte ursprünglich auf selbst betriebene Jitsi-Instanzen für Videokonferenzen und ein eigenes RTMP-Ingest-Setup für Live-Streaming. Das lief auf dedizierten Bare-Metal-Servern bei einem Rechenzentrumsanbieter. Für die ersten Kunden war das ausreichend – weil die Nutzung moderat war und die Last planbar.

Mit wachsendem Geschäft wurde genau dieses Setup zum operativen Albtraum, weil Video-Workloads ein Muster haben, das klassische Serverarchitekturen schlecht bedienen: extrem volatile Last.

Ein normales Meeting am Dienstag nutzt wenige Ressourcen. Ein angekündigter Produktlaunch mit 3.000 Zuschauern ist ein ganz anderes Systemverhalten. Und dreißig Minuten nach dem Event ist der Ressourcenbedarf wieder fast auf Null.

Bare Metal kann das. Aber nur, wenn man „Worst Case" dauerhaft bezahlt.

Wo es knirschte: Skalierung, Resilienz, Distribution und Souveränität

Die Skalierung war der erste Engpass. Jitsi-Videobridges sind CPU- und RAM-hungrig; bei größeren Meetings belegt ein einzelner Prozess schnell mehrere Kerne und zweistellige GB RAM. Neue Kapazität bedeutete: Server bestellen, OS installieren, Jitsi konfigurieren, DNS anpassen. Zwei bis fünf Werktage Vorlaufzeit – für kurzfristige Großeinsätze unbrauchbar.

Noch gefährlicher war die Fragilität der Streaming-Pipeline. Der RTMP-Ingest lief auf einem einzigen Server. Fiel er aus, war der Stream weg. Kein Failover, kein automatischer Neustart, kein Self-Healing. Genau das passierte bei einer CEO-Townhall eines DAX-Konzerns: nach 20 Minuten brach der Stream ab. Der Vertrag wurde nicht verlängert.

Kunden verlangten außerdem Multi-Destination-Streaming. Die Plattform sollte einen Stream gleichzeitig auf der eigenen Plattform, auf YouTube, LinkedIn Live und interne Intranet-Seiten ausspielen. Die bestehende Architektur konnte einen Stream nur an ein Ziel schicken. Kunden mussten OBS und eigenes RTMP-Setup nutzen – für nicht-technische Nutzer ein Ausschlusskriterium.

Auch die Nachbearbeitung war Handarbeit. Aufzeichnungen lagen als Rohdateien auf dem Server. Transkodierung in mehrere Qualitätsstufen, Thumbnail-Generierung und das Einstellen in die On-Demand-Bibliothek erfolgten manuell, oft erst Tage später. Kunden erwarteten Minuten.

Und schließlich: Qualität und Isolation. Jitsi funktionierte gut bis etwa 20 Teilnehmer. Darüber hinaus nahm die Qualität spürbar ab. Gleichzeitig teilten sich alle Kunden dieselben Bridges und Streaming-Server – ein intensives Event konnte andere Kunden beeinträchtigen. Garantierte Servicequalität war so unmöglich.

Parallel entstand ein Souveränitätsproblem. Teile der Transkodierung liefen über einen US-basierten Cloud-Dienst. Kunden aus öffentlichem Sektor und regulierten Branchen wollten eine vollständig europäische Lösung ohne US-Abhängigkeiten – Streambase konnte das nicht durchgängig garantieren.

Der Wendepunkt war ein Großdeal: Ein Versicherungskonzern wollte Streambase für quartalsweise Investoren-Calls nutzen – mit SLA 99,95 % während des Events und maximal 3 Sekunden Latenz, inklusive Aufzeichnung und Multi-Sprach-Support. Das Engineering-Team wusste: Mit dem bestehenden Setup ist das nicht darstellbar.

ayedos Ansatz: Video als Plattform-Workload – elastisch, isoliert, automatisiert

Wir sind nicht mit dem Ziel gestartet, „mehr Server" zu liefern. Das hätte nur den Worst-Case-Betrieb teurer gemacht.

Das Ziel war eine Kubernetes basierte Video-Infrastruktur, die den gesamten Lifecycle abdeckt:

• Echtzeitkommunikation (WebRTC) skalierbar betreiben
• Live-Ingest und Distribution resilient und multi-destination-fähig machen
• Aufzeichnung und Transcoding automatisieren und horizontal skalieren
• Kunden sauber isolieren, um Servicequalität garantieren zu können
• alles auf europäischer Infrastruktur, ohne US-Abhängigkeiten

LiveKit statt Jitsi als primäre WebRTC-Engine – weil Skalierung hier entscheidet

Der zentrale Baustein war der Wechsel der WebRTC-Grundlage.

Jitsi kann Meetings – aber die Architektur ist für großskalige, dynamische Lastprofile nicht optimiert. LiveKit hingegen ist von Grund auf darauf ausgelegt, als skalierbarer Dienst zu laufen. Jeder LiveKit-Server läuft als Pod und kann horizontal skaliert werden. Für kleine Meetings reicht eine Basiskapazität. Für große hybride Events werden automatisch zusätzliche Pods hochgefahren.

LiveKit nutzt SFU-Mechanismen, Simulcast und Dynacast: Clients bekommen automatisch die passende Qualität für Bandbreite und Endgerät. Das ist im Enterprise-Kontext entscheidend, weil die Zuschauer-Umgebung heterogen ist: VPNs, mobile Netze, Corporate Firewalls.

Für Großevents mit tausenden passiven Zuschauern ist WebRTC nicht immer das effizienteste Auslieferungsformat. Deshalb wird der WebRTC-Stream für diese Szenarien in einen HLS-Egress überführt, der für massenhafte Verteilung besser geeignet ist – ohne dass Kunden zwischen zwei Systemen wechseln müssen.

Jitsi blieb als Option erhalten – aber als Self-Service-Variante für Kunden, die bewusst eine klassische Meetinglösung ohne tiefere Plattformintegration wollen. Der Unterschied: Auch Jitsi läuft nun auf Kubernetes und kann kundenisoliert betrieben werden.

Multi-Destination-Streaming als Produktfeature – mit Restreamer

Multi-Destination war kein „Nice-to-have", sondern ein Verkaufsargument. Dafür haben wir Restreamer (datarhei) integriert: Ein eingehender Stream wird automatisch an beliebig viele Ziele parallel weitergeleitet – Plattform, YouTube Live, LinkedIn Live, Intranet-Player, Partner-CDNs.

Wichtig war hierbei nicht nur die technische Fähigkeit, sondern die Bedienbarkeit. Kunden konfigurieren Ziele über eine UI, ohne RTMP-Know-how und ohne zusätzliche Tools. Und Restreamer läuft als Deployment mit Autoscaling, basierend auf aktiven Streams und Ausgabezielen.

Damit wird Multi-Destination von „Kunde muss OBS bedienen" zu „Plattform kann das".

Automatisierte Video-Processing-Pipeline: Von Rohdatei zu On-Demand in Minuten

Aufzeichnungen werden nach Event-Ende automatisch in eine Processing-Pipeline überführt. Transcoding in mehrere Qualitätsstufen, Thumbnail-Generierung und optional Untertitel sind Teil eines standardisierten Jobsystems, das horizontal skaliert.

Das ist ein typischer Kubernetes Usecase: Viele ähnliche Jobs, parallelisierbar, mit klarer Ressourcenzuordnung. Bei Spitzen – etwa nach einem großen Event-Tag mit vielen parallelen Aufzeichnungen – werden automatisch zusätzliche Transcoding-Worker hochgefahren. Danach skaliert die Pipeline wieder zurück.

Damit werden Aufzeichnungen nicht mehr Tage später manuell „aufbereitet", sondern sind typischerweise innerhalb von Minuten verfügbar.

Autoscaling auf Pod- und Node-Ebene: Ressourcen nur dann, wenn sie gebraucht werden

Video-Plattformen scheitern häufig an einem ökonomischen Problem: Sie bezahlen dauernd den Worst Case, um einmal im Quartal einen Peak bedienen zu können.

Mit Horizontal Pod Autoscaling skaliert die Plattform die Dienste (LiveKit, Processing-Worker, Restreamer) dynamisch. Zusätzlich sorgt Node Autoscaling dafür, dass die Clusterkapazität nachzieht, wenn Pods mehr Ressourcen benötigen.

Vor angekündigten Großevents kann Kapazität proaktiv hochgefahren werden, nach dem Event fährt sie automatisch zurück. Das ist der Kern der wirtschaftlichen Transformation: weg vom dauerhaften Überprovisionieren, hin zu elastischem Verbrauch.

Mandantentrennung: Servicequalität wird garantierbar

Ein unterschätzter Teil bei Video ist Isolation. Ein Kunde mit großem Event darf nicht die Meetingqualität anderer Kunden beeinträchtigen.

Jeder Kunde läuft in einem eigenen Namespace mit Resource Quotas und Network Policies. Für Enterprise-Kunden können dedizierte Node Pools bereitgestellt werden, die garantierte Ressourcen bieten. Damit entsteht nicht nur technische Stabilität, sondern ein SLA-fähiges Betriebsmodell.

Observability: Video-spezifische Metriken statt „Server lebt"

Mit VictoriaMetrics, VictoriaLogs, Grafana und Tempo haben wir einen Observability-Stack aufgebaut, der Video-Realität abbildet: Bitrate, Paketverlust, WebRTC-Verbindungsqualität, Teilnehmerzahlen, Egress-Latenzen, Queue-Längen im Transcoding, Fehlerquoten pro Stream.

Das ist entscheidend, weil Video-Probleme oft nicht „down" sind, sondern „degraded". Wer nur Uptime misst, erkennt Probleme erst, wenn Zuschauer sich beschweren. Streambase kann jetzt Qualitätseinbrüche erkennen und reagieren, bevor sie im Event sichtbar werden.

GitOps und Identity: Betrieb wird reproduzierbar, Zugriff wird steuerbar

ArgoCD verwaltet Infrastruktur und Konfiguration per GitOps. Änderungen an Kunden-Namespaces, Policies und Plattformdiensten sind versioniert, reviewbar und nachvollziehbar.

Authentik liefert SSO für Plattform-Administration, Kundenzugänge und die Anbindung an Kundenverzeichnisse. Für Enterprise-Kunden ist das nicht Komfort, sondern Voraussetzung.

Ergebnis: Großevents werden zuverlässig – und die Kosten sinken

Mit der neuen Plattform konnte Streambase erstmals die Anforderungen des Versicherungskonzerns erfüllen. Quartalsweise Investoren-Calls laufen stabil mit Live-Stream, Aufzeichnung und Multi-Sprach-Support – bei unter zwei Sekunden Latenz und einer gemessenen Verfügbarkeit von 99,98 % während der Events.

Skalierung passiert nicht mehr in Werktagen durch Serverbestellung, sondern in Minuten durch Autoscaling. Unerwartete Lastspitzen werden automatisch abgefangen. Nach Events laufen keine leeren Server wochenlang weiter.

Multi-Destination-Streaming ist ein Produktfeature geworden. Aufzeichnungen stehen innerhalb von fünf bis fünfzehn Minuten in der Bibliothek bereit, nicht Tage später.

Die Infrastrukturkosten sanken um über 50 %, weil Kapazität nicht mehr dauerhaft auf den Worst Case dimensioniert wird.

Kundenisolation sorgt dafür, dass ein Event eines Kunden nicht die Qualität anderer Kunden beeinträchtigt. SLAs werden dadurch überhaupt erst seriös.

Und die Souveränitätsanforderung ist erfüllt: Ingest, Processing, Storage und Distribution laufen vollständig auf europäischer Infrastruktur, ohne US-Cloud-Abhängigkeit.

Warum dieser Ansatz funktioniert

Video ist die Domäne unvorhersehbarer Last. Genau deshalb ist eine Plattformarchitektur, die elastisch und automatisiert reagiert, der entscheidende Wettbewerbsvorteil.

LiveKit liefert das skalierbare WebRTC-Fundament. Kubernetes liefert Scheduling, Autoscaling und Self-Healing. GitOps macht Betrieb reproduzierbar. Observability macht Qualität steuerbar. Mandantentrennung macht SLAs belastbar. Und Self-Hosting auf europäischer Infrastruktur macht das Ganze verkaufbar in regulierten Branchen.

Call to Action

Wenn ihr Video- oder Streaming-Workloads betreibt und noch über dedizierte Server, manuelle Provisionierung oder Single-Point-Ingest arbeitet, seid ihr in einem Muster gefangen, das bei Wachstum zwangsläufig teuer und riskant wird.

ayedo baut Kubernetes basierte Video-Infrastrukturen für skalierbares WebRTC, resilientes Live-Streaming, Multi-Destination-Distribution und automatisiertes Processing – inklusive Mandantentrennung, Observability und europäischer Souveränität.

Wenn ihr große Events SLA-fähig bedienen wollt, ohne dauerhaft den Worst Case zu bezahlen, lasst uns sprechen. Wir schauen gemeinsam auf eure Lastprofile, eure Architektur und eure Qualitätsanforderungen – und leiten daraus eine Plattform ab, die technisch und wirtschaftlich trägt.