Im Live-Streaming ist ein Fehler kein schleichender Qualitätsverlust, sondern ein sofortiger, für den Nutzer sichtbarer Vorfall. Netflix begegnet diesem Problem, indem es Qualitätskontrolle und Priorisierung direkt in die Origin-Schicht verlagert.
Die Hauptgrenze zeigt sich dort, wo VOD-Ansätze nicht mehr funktionieren. Im Live-Betrieb gibt es keinen Zeitpuffer: Ein Segment muss innerhalb von Sekunden kodiert, ausgeliefert und gecacht werden. Jede Verzögerung beim Schreiben oder jeder Segmentdefekt wirkt sich unmittelbar auf den Zuschauer aus. Zusätzlich konkurriert das System um Ressourcen: Das Schreiben von Segmenten, das Lesen durch das CDN und Verkehrsspitzen (insbesondere am Live-Edge) finden gleichzeitig statt. Bei Dutzenden Millionen Nutzern führen selbst kurzfristige Storage-Ausfälle oder unnötige Anfragen an das Origin zu einer Kaskade von Qualitätsverlusten.
Netflix hat sich für eine Architektur entschieden, bei der Live Origin nicht nur ein Storage-Endpunkt, sondern eine aktive Entscheidungsschicht ist. Der Schlüssel: Live-Pipelines werden in verschiedenen Regionen dupliziert und das „erste valide“ Segment wird ausgewählt. Dadurch sinkt die Wahrscheinlichkeit, defektes Video auszuliefern, ohne dass komplexe Synchronisation zwischen den Pipelines nötig ist. Ein weiterer wichtiger Trade-off ist der Verzicht auf dynamische Manifeste zugunsten von Segmentvorlagen mit fester Dauer. Das macht das Systemverhalten vorhersehbar und ermöglicht es dem Origin, zu berechnen, wann ein Segment „erscheinen muss“, erfordert aber strikte Disziplin beim Encoding und Timing.
Die Umsetzung basiert auf einem einfachen, aber streng kontrollierten Vertrag: Der Packager schreibt Segmente per HTTP PUT, das CDN liest sie per HTTP GET über dieselbe URL. In dieser einfachen Schnittstelle steckt Logik: Der Packager fügt Metadaten zu Defekten hinzu, und das Origin wählt beim Abruf das beste Segment aus mehreren Pipelines aus. Ist ein Segment noch nicht bereit, antwortet das Origin nicht immer mit 404 – am Live-Edge kann es die Verbindung bis zur Veröffentlichung offenhalten, um unnötigen Traffic zu vermeiden. Das CDN (Open Connect) optimiert zusätzlich: Es cached sogar 404-Antworten mit präzisem TTL und blockiert unmögliche Anfragen anhand des Segmentvorlagenmusters. Für Millisekunden-Genauigkeit hat Netflix das Standard-HTTP-Caching um eigene Header erweitert.
Eine zusätzliche Komplexitätsschicht ist das Storage. S3 erwies sich als nicht ausreichend vorhersehbar für ein 2-Sekunden-SLA beim Schreiben. Netflix wechselte zu einer Abstraktion auf Basis von Cassandra mit Chunking großer Objekte und lokalem Quorum, um Zonen-Ausfälle und hohe Write-Availability zu verkraften. Das verbesserte die Latenz, offenbarte aber einen Konflikt: Bei Spitzen im Lesezugriff (Origin Storm) verschlechterte sich das Schreiben. Die Lösung: Write-Through-Cache (EVCache), der nahezu den gesamten Lese-Traffic übernimmt und so die Schreibstabilität sichert. Parallel wurde eine vollständige Pfad-Isolierung eingeführt: separate Compute-Stacks, getrennte Lese-/Schreib-Cluster und unabhängige Skalierungspfade.
Das Ergebnis: Das System steuert nicht nur Daten, sondern auch Prioritäten. Das Schreiben von Segmenten ist immer kritisch, danach folgt der Live-Edge, dann DVR. Bei Überlastung setzt das Origin priorisiertes Rate Limiting ein und gibt sogar gezielt 503 mit TTL zurück, um wiederholte Anfragen zu „beruhigen“. Diese Kombination – vorhersehbare Vorlagen, redundante Pipelines, Schreibisolierung und aggressives Caching – ermöglicht es dem System, Dutzende Millionen gleichzeitiger Streams ohne Qualitätsverlust zu bewältigen. Die Metriken zeigen eine deutliche Reduktion der Storage-Latenz und Stabilität bei extremem Lese-Durchsatz, auch wenn die Lösung teurer ist – eine bewusste Entscheidung zugunsten der Zuverlässigkeit.