# Netflix Netflix operates Open Connect, a content-delivery infrastructure program using embedded appliances and ISP peering to localize and efficiently deliver Netflix traffic. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## MAPS: Netflix's Multimodal Asset Personalization at Scale DevFeed: [MAPS: Netflix's Multimodal Asset Personalization at Scale]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-08-28T16:01:02Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Netflix](), [personalization](), [Embeddings](), [multimodal](), [recommendation systems](), [data](), [A/B Testing]() Tags: [data](), [embedding](), [embeddings](), [machine-learning](), [model](), [multimodal](), [netflix](), [personalization](), [production](), [testing]() ### AI overview Netflix describes MAPS, a multimodal asset-personalization system that uses embeddings from artwork and video previews to address cold-start problems and personalize recommendations soon after a title launches. ### Source excerpt By Emma Yanyang Kong, Aditya Deshpande, Asad Abbasi, Bowei Yan, David Fagnan, Ashish Rastogi, Dhaval Patel, Ray Zhang Introduction The Netflix experience is a journey of discovery. Every visual cue, from the artwork on a title to the video previews that autoplay while you browse, is there to connect you with a story you will love. We call these visual cues assets, and choosing the right one for each member is a personalization problem of its own. But which image or video preview of Squid Game should we show you? And what do we do right after a title launches, when there's far too little interaction data to know which asset we should recommend to each member? For years, our models answered the first question well and the second poorly. They learned which assets members interacted with, but treated every asset as an opaque ID, blind to what was actually in the artwork or video preview. Right after a title launched, its assets had no history, so we dialed up exploration on its assets to gather interaction data, and otherwise fell back to popularity heuristics that ignore your taste. Only once enough interactions had piled up could personalization take over. This is the classic cold-start problem. This post shares how multimodal embeddings let our models see and hear the assets they recommend, so personalization can kick in far sooner, close to a title's launch. Because a new asset arrives with its embedding the model already understands, that embedding carries member taste signals from related assets immediately. Consequently, the model needs far less interaction history before it can personalize. We cover three production systems, artwork personalization, query-aware artwork ranking, and video preview personalization, plus a cheap trick for choosing new embeddings before committing to full end-to-end integration and A/B testing. Artwork Personalization A single image is often a member's first touchpoint with a title, so we create a diverse set of artworks for each tit ## A Tale of Two Flink Autoscalers DevFeed: [A Tale of Two Flink Autoscalers]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-08-21T16:01:01Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [apache-flink](), [autoscaling](), [Netflix](), [stream-processing](), [Kafka](), [Open Source](), [telemetry](), [Network]() Tags: [apache-flink](), [autoscaling](), [aws](), [infrastructure](), [kafka](), [metrics](), [netflix](), [open-source](), [operational-excellence](), [scale](), [stream-processing](), [telemetry]() ### AI overview Netflix describes running two Apache Flink autoscalers: an older in-house system and a newer one from the Apache Flink community. The article explains why autoscaling is necessary for more than 30,000 Flink jobs across AWS regions, discusses workload variability and the cost of resizing stateful jobs, and introduces the metrics-driven design of the first autoscaler. ### Source excerpt Samuel Yeboah, Francesco Di Chiara and Mingliang Liu Today, Netflix runs two Flink autoscalers. That is exactly one more than we want. We built the first one in-house years ago, when there was no mature option suited to our platform. The second came from the Apache Flink community, and it can scale workloads our homegrown system was never designed for. We now run both in production and are steadily converging on the open-source one. Along the way we learned some hard lessons about metrics, cost, and the real price of maintaining infrastructure you could instead adopt, and we hope they are useful whether you run a handful of Flink jobs or tens of thousands. Why autoscaling is not optional at our scale Netflix has run stream processing on Apache Flink since 2017. As of 2026 we operate more than 30,000 Flink jobs across multiple AWS regions. Most are not deployed by hand; they are generated by our managed platform Data Mesh, so the majority of users never touch a Flink job directly. A smaller but growing set are custom jobs, built and operated by teams across the company for use cases like personalization, Ads, and Live events. They range from single-operator jobs that shuttle records between Kafka topics to stateful pipelines with branches, joins, and terabytes of state, and their load swings with daily cycles, launches, and regional failovers. Provisioning every one of those jobs for its peak is wasteful; provisioning for the average causes lag during surges. And in our platform a scaling action is not free: by default it means taking a savepoint, stopping the job gracefully, and restarting it at the new size, which for a large stateful job can take minutes. That leaves a genuinely hard question: how do you give each job the resources it needs, when it needs them, without a human in the loop and without breaking anything? The first autoscaler: watching from outside Our first answer, built around 2019, was an autoscaler shaped like a stream-processing job. It ran on M ## How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC... DevFeed: [How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC...]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-08-07T16:01:02Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Graphs](), [gRPC](), [Netflix](), [real-time](), [Latency](), [API](), [Streaming](), [personalization](), [Security](), [apache-flink]() Tags: [apache](), [apache-flink](), [api](), [data](), [data-processing](), [events](), [latency](), [netflix](), [personalization](), [real-time](), [security](), [streaming]() ### AI overview Netflix's third-part blog post describes the serving layer for its Real-Time Distributed Graph and explains how gRPC enables efficient graph querying. It focuses on serving diverse workloads, including security lookups and personalization traces, with sub-100ms responses across a billion-edge graph. ### Source excerpt How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC execution API Authors: Nilesh Mishra and Ajit Koti This is the third entry of a multi-part blog series describing how we built a Real-Time Distributed Graph (RDG). In Part 1, we discussed the motivation for creating the RDG and the architecture of the data processing pipeline that populates it. In Part 2, we discussed how we designed the storage layer to handle billions of nodes and edges while maintaining single-digit-millisecond latency. In Part 3, we will explore how we designed a fast, flexible serving layer to efficiently query the graph. Introduction In Part 1 of this series, we described why Netflix needed a Real-Time Distributed Graph (RDG) and how we used Apache Flink to build an ingestion and processing pipeline that turns streaming events into graph primitives. In Part 2, we explored how we designed a storage layer capable of handling billions of nodes and edges while still delivering single-digit-millisecond latency. In this post, we focus on the next challenge: querying the graph efficiently to power real-time insights for our internal partners. All of the work on ingestion and storage only matters if we can actually ask complex questions and get answers back quickly. As we optimized for lower latency, we found that the serving layer posed its own set of challenges, distinct from those of ingestion and storage. How do we turn a constantly evolving, billion-edge graph into sub-100ms responses across a wide variety of workloads? This is the problem we tackle in this post. The Real World Needs As we integrated the RDG into Netflix's ecosystem, we realized that "querying the graph" is not a one-size-fits-all operation. We needed to handle a wide range of access patterns: from high-volume security lookups to deep, exploratory personalization traces. Let's revisit our example from Part 1 and expand on it slightly. In the earlier posts, we focused on accounts, device ## Kimi K3 Goes Open, Netflix Ranks with an LLM, and an Agent Breaks Into Hugging Face - The Tokenizer Edition #35 DevFeed: [Kimi K3 Goes Open, Netflix Ranks with an LLM, and an Agent Breaks Into Hugging Face - The Tokenizer Edition #35]() Original publisher: [Read original article]() Author: Sairam Sundaresan Published: 2026-08-03T12:02:21Z Content type: article Language: en Sources: [Gradient Ascent]() Topics: [Large Language Model](), [Artificial Intelligence](), [Machine learning](), [AI Agent](), [hugging face](), [Netflix]() Tags: [agent](), [ai](), [hugging-face](), [llm](), [netflix]() ### AI overview This newsletter edition curates AI and machine-learning resources covering Moonshot's open 2.8-trillion-parameter Kimi K3 model, Netflix's use of language models for ranking, GUI agents, MCP, and a reported Hugging Face infrastructure intrusion involving an AI agent. ### Source excerpt This week's most valuable AI resources ## Modeling Device Capabilities for Analytics DevFeed: [Modeling Device Capabilities for Analytics]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-07-31T16:01:02Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Netflix](), [data](), [data-processing](), [datasets](), [Hardware](), [cpu](), [Streaming](), [Software]() Tags: [analytics](), [cloud-gaming](), [cpu](), [data](), [data-engineering](), [data-modeling](), [datasets](), [devices](), [hardware](), [netflix](), [streaming]() ### AI overview Netflix describes a device-capability data model for analytics across a diverse ecosystem of streaming devices. Cumulative and histogram tables capture device capabilities, active device counts, software versions, and feature support, helping teams measure feature reach and make more granular enablement decisions. ### Source excerpt by Aarti Laddha, Richard Diaz-Cool, Rishika Idnani, Venkatesh Selveraj Netflix supports a vast and evolving set of features and content types, ranging from 4K streaming and immersive audio to live streaming and cloud gaming, across a diverse ecosystem of devices. However, not all devices are created equal. Hardware limitations such as available RAM, CPU cores, display capabilities, or platform support mean that some features cannot be supported on certain device models. To ensure the best possible user experience, we rely on a deep understanding of device capabilities. We have invested in building a comprehensive device capability data model and integrating feature flags from internal systems, paving the way for smarter, more granular feature management across our global device landscape. This approach helps us identify bottlenecks in feature penetration and accelerates the pace of innovation. We have designed our data storage and modeling strategies to efficiently support analytics at scale. We use a cumulative table to process information about the device's capabilities. This table is structured to efficiently capture the latest state of each device and its associated capabilities (like Screen resolutions, Video Profiles Supported, Surround Sound, RAM size etc) making it ideal for analytics and reporting use cases. { "Screen Height": ["720"], "Screen Width": ["1280"], "Video Profiles": [ "playready", "hevc", ], } For aggregate analytics, we leverage a histogram table that captures active device counts over the past 28 days, broken down by device model and software version. This table also records the number of devices supporting specific capabilities, enabling detailed distribution analysis. One use case for this histogram data is to analyze the distribution of external display capabilities attached to streaming sticks. For example, the histogram below shows that out of total X number of devices, all supported the HD profile (playready), while only 20% devices sup ## GenRec: Towards LLM-Native Recommendation at Netflix DevFeed: [GenRec: Towards LLM-Native Recommendation at Netflix]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-07-30T20:10:15Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Netflix](), [recommendation systems](), [Large Language Model](), [LLM Techniques](), [personalization](), [vllm]() Tags: [data](), [feature-engineering](), [genai](), [large-language-models](), [large-language-models-llms](), [llm](), [llms](), [netflix](), [personalization](), [ranking](), [recommendation-system](), [vllm]() ### AI overview Netflix presents GenRec, an LLM-backed recommendation ranker trained on Netflix-specific data and objectives. It converts user histories, item metadata, and context into text, uses a catalog-aware scoring head, aligns recommendations with long-term member value and business goals, and runs in prefill-only mode on Netflix's LLM serving stack. In a large-scale A/B test, GenRec improved short- and long-term online metrics while using fewer labeled examples and input signals than a mature production ranker. ### Source excerpt Authors: Ying Li, Arjun Rao, Shradha Sehgal Introduction Recommendations sit at the heart of the Netflix experience. Our current production models rely on thousands of hand-crafted features over users, items, and interactions, along with specialized architectures for sequence modeling, feature interactions, and multi-task objectives. This stack has evolved over many years to support diverse content types (movies, series, games, live, podcasts) and product surfaces, but its complexity makes it costly to onboard new use cases: adding a content type or surface can require significant feature engineering, architecture change, infrastructure work, and experimentation. At the same time, large language models (LLMs) are changing how we think about recommendation, as shown by recent work such as PLUM, GLIDE, and OneRec-Think. Their broad world knowledge and strong language understanding make it possible to represent user histories and item metadata directly as text, capture rich relationships in a shared semantic space, and steer recommendations via natural-language prompts. However, off-the-shelf LLMs are still far from production-ready recommenders: they often over-recommend globally popular content, hallucinate out-of-catalog items, ignore business constraints, and provide only limited personalization. To address this, we built GenRec, an LLM-backed recommendation ranker that post-trains an internal foundation LLM on Netflix-specific data and objectives. GenRec shows that an LLM-based ranker can match or exceed a mature production system while relying on far fewer labeled examples and input signals. Figure 1: GenRec pipeline. Raw logs of user history, item metadata, and context are transformed via context engineering into natural-language prompts and fed into the GenRec, which runs on vLLM in prefill-only mode and outputs scores for each catalog item, yielding a recommendation ranking. At a high level, GenRec: Verbalizes user histories, item metadata, and context as text ## How Netflix Builds Reliable Systems for Live Streaming DevFeed: [How Netflix Builds Reliable Systems for Live Streaming]() Original publisher: [Read original article]() Author: Nikki Siapno Published: 2026-07-18T14:46:05Z Content type: article Language: en Sources: [Level Up Coding System Design Newsletter]() Topics: [Netflix](), [Streaming](), [Architecture & Design](), [systems](), [Cloud]() Tags: [engineering](), [live-streaming](), [netflix](), [streaming](), [systems]() ### AI overview The article explains why live streaming is harder than video on demand and describes Netflix's reliability challenges, including real-time processing, simultaneous viewers, fluctuating networks, missing segments, retry storms, and regional traffic spikes. ### Source excerpt How does Netflix stream live events without crashing? ## In-House LLM Serving at Netflix DevFeed: [In-House LLM Serving at Netflix]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-07-17T21:32:39Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [LLMs](), [Netflix](), [Inference](), [AI Platform](), [model-deployment](), [autoscaling](), [GPU](), [gRPC]() Tags: [ai](), [ai-platform](), [autoscaling](), [deployment](), [gpu](), [inference](), [llm](), [model-serving](), [netflix](), [platform-engineering]() ### AI overview Netflix describes its in-house LLM serving stack, covering deployment, inference, API access paths, and production trade-offs. ### Source excerpt By AI Platform's Model Runtime team and Inference team Introduction Most organizations consume LLMs through hosted APIs. Netflix went further -- we run the full stack ourselves, from model deployment through inference, inside our existing production environment rather than a separate ML silo. Some of those decisions weren't obvious, and a few revealed their trade-offs only under production load. This post focuses on the choices where alternatives were seriously considered: engine selection, model packaging, API surface design, deployment strategy, and output constraints enforcement. The goal is to share not just what was built, but why -- and what production revealed that the design phase didn't anticipate. Architecture Overview Member-scale ML at Netflix is fronted by a unified JVM-based serving system that handles the end-to-end flow for downstream consumers: routing and A/B test logic, candidate generation, feature fetching, inference, post-processing, and logging at each stage. Both real-time and cached batch paths are supported. Figure 1 shows the two ways callers reach inference today: the gRPC path through this serving system and a direct HTTP path used by newer LLM-driven applications. Where inference runs depends on the model. Small CPU models run in-process, avoiding remote-call overhead. Larger models need GPUs -- the serving system handles pre- and post-processing locally but delegates inference to a remote service, Model Scoring Service (MSS). MSS is the shared inference backend, supporting XGBoost, TensorFlow, PyTorch, and LLMs behind a unified interface, with NVIDIA Triton Inference Server underneath managing model loading, batching, and GPU scheduling. On top of Triton sits a Java control plane that handles deployment, versioning, health checking, autoscaling, and multi-region rollout. Model authors package their artifacts and configure the deployment; the control plane provisions GPU instances, configures Triton, and orchestrates zero-downtime upgrades ## Vercel's Agent Framework, Netflix's Generative Homepage, and a Repo That Writes Less Code: The Tokenizer Edition #33 DevFeed: [Vercel's Agent Framework, Netflix's Generative Homepage, and a Repo That Writes Less Code: The Tokenizer Edition #33]() Original publisher: [Read original article]() Author: Sairam Sundaresan Published: 2026-07-05T05:27:18Z Content type: article Language: en Sources: [Gradient Ascent]() Topics: [Artificial Intelligence](), [Agent Skill](), [ZEIT](), [AI-assisted coding](), [Netflix]() Tags: [ai](), [coding](), [coding-agents](), [generative](), [models](), [netflix](), [tools](), [vercel]() ### AI overview This newsletter edition curates AI and machine learning resources, including papers, videos, articles, tools, and learning materials. Topics include Program-as-Weights, bounded-memory long-horizon agents, coding-agent benchmarks, Netflix's model-generated homepage, Vercel's file-first framework for durable agents, and tools for distributed model inference. ### Source excerpt This week's most valuable AI resources ## How the FAANG Acronym Evolved into MAMAA, MANGO, and MANGOS DevFeed: [How the FAANG Acronym Evolved into MAMAA, MANGO, and MANGOS]() Original publisher: [Read original article]() Author: Prasad Rao Published: 2026-07-02T22:39:16Z Content type: opinion Language: en Sources: [Big Tech Careers]() Topics: [Tech Careers](), [amazon](), [Google](), [Meta](), [Microsoft](), [Netflix]() Tags: [2025](), [2026](), [careers](), [company](), [faang]() ### AI overview The article traces the evolution of the acronym used for major technology companies, from FANG and FAANG to MAMAA, MANGO, and MANGOS. It explains how company rebranding, market leadership, and changes in capital and talent influenced each revision. ### Source excerpt What's in the acronym? ## GenPage: Towards End-to-End Generative Homepage Construction at Netflix DevFeed: [GenPage: Towards End-to-End Generative Homepage Construction at Netflix]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-06-29T13:01:02Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Netflix](), [recommendation systems](), [Large Language Model](), [Machine learning](), [Reinforcement learning](), [Transformer]() Tags: [ai](), [app](), [diversity](), [engineering](), [feature-engineering](), [generation](), [generative](), [large-language-models](), [machine-learning](), [model](), [netflix](), [optimization](), [ranking](), [recommendation-system](), [reinforcement-learning](), [rl]() ### AI overview This Netflix developer article introduces GenPage, a generative approach that uses a single autoregressive model to construct a personalized homepage by generating recommendation rows, entities, and layout together. It describes replacing a multi-stage recommendation pipeline with end-to-end modeling and using reinforcement learning to optimize whole-page rewards, including interactions such as diversity and the balance between rows. ### Source excerpt Authors: Lequn Wang, Jiangwei Pan, and Linas Baltrunas Figure 1. Autoregressive homepage generation. GenPage builds a Netflix homepage one row or entity at a time, each one conditioned on what's already on the page and the user's context.Introduction The Netflix homepage is the first thing users see when they open the app and the primary way they discover content to enjoy. Almost every part of it is personalized, including which rows appear, which entities show up within those rows, and how everything is arranged on the page. Constructing that homepage is a genuinely hard problem. It is not simply producing one ranked list. The homepage is a structured, two-dimensional layout, made up of recommendation rows and the entities within them. Here, an entity can be a movie, show, game, live event, or other recommendable item. Each choice can affect the value of the others. Traditionally, it is built through a complex, multi-stage pipeline, with separate components for candidate generation and ranking at both the row and entity levels. We saw an opportunity to rethink this design. Large language models have shown that a single generative model can perform diverse tasks just by generating a response to a prompt. Inspired by this prompt-response paradigm, we trained a single generative model to build the homepage by directly answering one question: Given everything we know about this user and this request, what homepage should we generate to maximize user satisfaction? We call this approach GenPage. It treats the user history and request context as the prompt, and autoregressively generates the entire homepage as the response (Figure 1). Unlike most generative recommenders, such as TIGER, HSTU, and OneRec, which generate flat ranked lists, GenPage generates the rows, entities, and layout together. This shift is motivated by several goals: End-to-end modeling. A single transformer model that constructs the page from raw input signals can replace a complex multi-stage recommen ## Toward More Controllable AI Video Editing: An Early Research Exploration at Netflix DevFeed: [Toward More Controllable AI Video Editing: An Early Research Exploration at Netflix]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-06-23T00:31:01Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Netflix](), [Artificial Intelligence](), [Generative AI]() Tags: [ai](), [generative](), [netflix](), [research](), [technology](), [video](), [workflows]() ### AI overview Netflix explores generative AI video editing methods designed to give artists precise control over changes while preserving source footage, creative intent, and physical continuity. The article discusses challenges including unintended edits and unnatural physics in professional video workflows. ### Source excerpt By Zhuoning Yuan, Ta-Ying Cheng, Benjamin Klein, Bahareh Azarnoush Introduction At Netflix, we build technology to help storytellers bring their creative visions to life and to help members discover the stories they love. To connect stories with diverse audiences around the world, we produce promotional assets, including trailers, teasers, and social short-form videos, that build on and elevate the original footage. Through close collaboration with the teams crafting these assets, we identified a recurring gap in current tools. Transforming raw footage into a polished final asset often requires complex edits like seamlessly adding new visual elements, patching or replacing backgrounds, or removing unwanted objects without breaking the scene's physical continuity. These tasks typically demand hours of specialized manual editing work. While recent generative video editing models show promise, they often struggle to preserve the integrity of the source footage. Many methods regenerate every pixel to make an edit, which can fail to isolate changes and inadvertently alter elements that should remain untouched. To execute these tasks effectively, artists need tools that empower them to dictate exactly what changes and how it changes. Our research goal is to make this process easier for artists. We're deliberate about where and how AI is applied, ensuring that the technology always serves the creative intent. That principle drives our recent work: exploring the benefits of generative AI in ways that protect and expand creative choice, and keeping artists in precise control of their final vision. Recent advancements in AI video editing have demonstrated impressive capabilities in streamlining complex manual editing workflows, but key challenges remain before they can reliably support professional use: Unintended edits: When editing a specific element in a video clip, many methods regenerate the entire video, which can inadvertently alter identity, performance, and other ele ## How Netflix Simplified Batch Compute with Kueue DevFeed: [How Netflix Simplified Batch Compute with Kueue]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-06-22T21:35:01Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [kueue](), [Netflix](), [Kubernetes](), [migration](), [Cloud](), [App]() Tags: [applications](), [aws](), [batch](), [cloud](), [compute](), [ecosystem](), [infrastructure](), [jobs](), [kubernetes](), [kueue](), [migration](), [netflix](), [platform](), [resource](), [work]() ### AI overview Netflix describes its transition toward a more Kubernetes-native compute infrastructure and its adoption of Kueue, a cloud-native job queueing system for batch workloads. The article explains how Kueue replaced custom queuing and scheduling logic in Compute Managed Batch, supported the migration of millions of batch jobs, and enabled tenant-based capacity management and workload execution through Titus. ### Source excerpt By Alvin Bao, Alex Petrov, Jennifer Lai, Aidan Sherr, and Samartha Chandrashekar As a part of the journey to transition Netflix's compute infrastructure to be more Kubernetes-native, we have leaned into incorporating components from the Kubernetes ecosystem into our container platform Titus. One example of this is our use of Kueue, a cloud-native job queueing system for batch workloads, which has largely replaced the custom queuing and scheduling logic in our homegrown managed batch solution Compute Managed Batch (CMB). In this post, we'll give an overview of what motivated the migration, how we migrated millions of batch jobs to use Kueue, and what Kueue allows us to offer as a Compute platform. Brief Overview of CMB and Titus CMB is a managed batch solution that allows users and applications to execute and manage workloads that run to completion. Using a tenant hierarchy, workloads are managed and queued with ordered execution through priorities, and capacity is managed on a per-tenant basis. Workloads that are submitted to CMB are then run on Titus. The features of Titus relevant to CMB are workload federation across multiple cells (Kubernetes clusters) and federated capacity reservations. This means CMB can talk to a single Titus endpoint to get/submit workloads and update capacity reservations without having to worry about the underlying cell/cluster topology. CMB Tenant Hierarchy Tenants provide a grouping mechanism for jobs submitted on behalf of certain organizations, platforms, or applications. Users can create and organize tenants however best suits their organization or use case. For example, an organization may use a single tenant across several applications or a complex hierarchical structure that matches its team and application ownership structure. Tenants are associated with a capacity configuration. The capacity configuration defines the amount of compute capacity available to the tenant and provides certain guarantees around isolation from other te ## Netflix's VOID: Fixing the Physics Problem in Video Editing DevFeed: [Netflix's VOID: Fixing the Physics Problem in Video Editing]() Original publisher: [Read original article]() Author: RisingStack Engineering Published: 2026-04-06T22:41:15Z Content type: article Language: en Sources: [RisingStack]() Topics: [AI Models](), [Artificial Intelligence](), [diffusion-transformers](), [Netflix](), [Simulation]() Tags: [ai](), [ai-models](), [diffusion](), [netflix](), [simulation](), [training](), [video]() ### AI overview The article explains Netflix's VOID model for removing objects from videos while also recomputing their downstream physical effects. It describes VOID as a counterfactual video-generation system using video diffusion and training data produced with physics simulation and human-object interaction data. ### Source excerpt There's a familiar trick in modern video editing with AI - taking an object out, slapping some new background in, - and calling it good. It does the trick for simple things, but it all falls apart the moment the object actually starts to move or interact with anything. Take a domino chain for example, [...] The post Netflix's VOID: Fixing the Physics Problem in Video Editing appeared first on RisingStack Engineering. ## How Netflix Built a Resilient Platform for WWE Raw's Weekly Live Broadcasts DevFeed: [How Netflix Built a Resilient Platform for WWE Raw's Weekly Live Broadcasts]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-01-06T23:05:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [Netflix](), [Streaming](), [Resilience](), [Amazon Web Services](), [observability](), [data]() Tags: [aws](), [live-streaming](), [netflix](), [observability](), [platform-innovation](), [real-time](), [resilience](), [servers](), [streaming]() ### AI overview This article examines how Netflix engineered a dedicated platform for WWE Raw's weekly live broadcasts. It describes redundant AWS ingest, low-latency CMAF/HLS segments, synchronized manifests, adaptive AVC and HEVC playback, Open Connect CDN delivery, and observability tooling, while noting remaining risks such as startup surges, origin contention, device diversity, and regional edits. ### Source excerpt What a difference a year makes. When Netflix secured WWE Raw, a three-hour weekly live broadcast with more than three decades of history, it marked a turning point. Raw is chaos in motion: fan-fueled, unpredictable, impossible to rehearse. And now Netflix has to make it flawless. More than a licensing play. It's an engineering gauntlet. Pulling it off means delivering a resilient platform that can handle global, live-grade performance every single week. Raising the Stakes Live streaming has, of course, been around for years. But the expectation that a global service can execute hours of live content flawlessly, at scale, every week, that's new. Raw sets the new bar for resilience. And from here on, every live product will be judged against that standard, whether it's financial trading, real-time auctions, or healthcare collaboration. How Netflix Built for Weekly Live To go beyond its on-demand stack, Netflix built a dedicated live media and data pipeline, piece by piece: Dual ingest with AWS MediaConnect and MediaLive for redundancy at the source. Two-second CMAF/HLS segments tuned for speed without overwhelming origin. Wall-clock aligned manifests to sync across devices and regions, even with edits. Adaptive ladders in AVC and HEVC balancing SD to 4K playback, mindful of constrained devices. Open Connect CDN with 18,000 servers in 6,000 locations, embedded in ISPs to slash startup time. Full-stack observability with Atlas, Mantis, and Lumen, surfacing drift and sync issues before users ever notice. For this approach, Netflix couldn't build on top of an old stack. They're deliberate adaptive platform choices that now set the standard for how live systems must be built. They had to replatform in a way that provided the most elasticity in the future. Fragile Points That Remain Even with this purpose-built pipeline, the weak spots look familiar to anyone running live systems: Start-time surges hammer manifest and session services in the opening seconds. Origin contenti ## How Netflix optimized its petabyte-scale logging system with ClickHouse DevFeed: [How Netflix optimized its petabyte-scale logging system with ClickHouse]() Original publisher: [Read original article]() Author: ClickHouse Published: 2025-10-23T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [log management](), [Netflix](), [Microservice](), [Amazon S3](), [Architecture & Design]() Tags: [amazon](), [amazon-s3](), [architecture](), [clickhouse](), [cost](), [data](), [database](), [debugging](), [logging](), [logs](), [microservices](), [monitor](), [netflix](), [scale](), [software](), [speed](), [storage]() ### AI overview This article explains how Netflix built and optimized a petabyte-scale logging system using ClickHouse. It describes an ingestion architecture spanning microservices, sidecars, Amazon S3, Amazon Kinesis, and a central routing application, along with generated lexers, custom protocol serialization, and sharded tag maps that enable high-throughput ingestion and fast interactive queries. ### Source excerpt "To make our logging system work, we had to make a lot of choices. The key is how you simplify things in order to do the least amount of work." Daniel Muino, Software Engineer ## Captionary Browser Extension Provides Subtitle Word Definitions on Netflix DevFeed: [Captionary Browser Extension Provides Subtitle Word Definitions on Netflix]() Original publisher: [Read original article]() Author: Furkan Kolcu Published: 2025-09-07T13:31:21Z Content type: release Language: en Sources: [Furkan Kolcu - Software Engineer Blog]() Topics: [Browser Extension](), [Extension](), [browser](), [Learning](), [Netflix](), [GitHub]() Tags: [browser](), [chrome-addon](), [english-learning](), [english-vocabulary](), [extension](), [firefox-addon](), [github](), [language-learning](), [language-learning-addon](), [learning](), [netflix](), [netflix-addon](), [technology]() ### AI overview Captionary is a browser extension for learning English through shows. It lets users click words in English Netflix subtitles to see definitions without leaving the screen. Support for other platforms and languages is planned. ### Source excerpt If you're watching movies or series to improve your English, you're not alone -- and you're doing it right. Subtitles can be a great way to pick up new words in context, especially when you hear how they're used in real conversations. ## How Netflix Uses Throttling to Prevent 4 Big Streaming Problems DevFeed: [How Netflix Uses Throttling to Prevent 4 Big Streaming Problems]() Original publisher: [Read original article]() Author: Richard Oliver Bray Published: 2024-08-15T13:02:09Z Content type: article Language: en Sources: [Hacking Scale by Better Stack]() Topics: [Netflix](), [Streaming](), [Back end](), [Amazon API Gateway](), [Cloud]() Tags: [api-gateway](), [backend](), [cloud](), [netflix](), [streaming]() ### AI overview The article explains how Netflix uses throttling to shield content playback from backend problems, including network failures, underscaled services, retry storms, and faulty deployments. It also describes the role of an API Gateway in routing and monitoring requests. ### Source excerpt Netflix reveals their unconventional trick to keep viewers happy ## Netflix's Transition from Multiple APIs to GraphQL Federation DevFeed: [Netflix's Transition from Multiple APIs to GraphQL Federation]() Original publisher: [Read original article]() Author: Ishwari Lokare Published: 2024-07-10T09:00:00Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Netflix](), [API](), [API Platform](), [Streaming](), [OpenAPI Specification](), [Tech Debt](), [Back end](), [Front end]() Tags: [api](), [api-platform](), [backend](), [community](), [development](), [frontend](), [graphql](), [netflix](), [openapi](), [streaming](), [tech-debt]() ### AI overview This article describes Netflix's evolution through four generations of APIs, from an API-first OpenAPI strategy and REST-based services to Falcor and eventually GraphQL Federation. It explains how the company used the graph to address API complexity, support collaboration, manage technical debt and reduce organizational barriers. ### Source excerpt Netflix is the world's most popular streaming service. While everyone knows how it paved the way for a whole new industry when it moved from its physical DVD business to the cloud, you may not know how Netflix's API platform powered that transition. As Bruce Wang, Director of Engineering of Games Platform at Netflix shared at a Champions Corner Webinar, they went through four generations of APIs before transitioning to GraphQL Federation. ## Behind the streams: how Netflix drives reliability across their organization DevFeed: [Behind the streams: how Netflix drives reliability across their organization]() Original publisher: [Read original article]() Published: 2024-07-02T09:04:13Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Netflix](), [Deployment](), [incident management](), [User experience (UX)]() Tags: [case-study](), [deployment](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [netflix](), [outage](), [post-mortem](), [site-reliability](), [slack-incident]() ### AI overview An episode discusses how Netflix deployed incident.io across its organization, using strong UX to roll it out to hundreds of teams within months. It also highlights Netflix's extensive Catalog and its partnership with incident.io. ### Source excerpt This week we sit down with Hank Jacobs, Staff Site Reliability Engineer at Netflix to discuss their deployment of incident.io across their organization. ## Redefining API Strategy: Why Netflix Platform Engineering Chose Federated GraphQL DevFeed: [Redefining API Strategy: Why Netflix Platform Engineering Chose Federated GraphQL]() Original publisher: [Read original article]() Author: Ishwari Lokare Published: 2024-03-13T12:37:32Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Netflix](), [Platform Engineering](), [API](), [Streaming](), [systems]() Tags: [api](), [apollo-federation](), [architecture](), [decoupling](), [events](), [graphql](), [monolithic-architecture](), [netflix](), [platform-engineering](), [scale](), [streaming]() ### AI overview The article examines Netflix's 15-year evolution across five generations of APIs and its adoption of federated GraphQL. It describes how Netflix used Apollo Federation to unify APIs across platforms, decouple domain teams, and support independent API ownership while retaining an integrated Consumer Edge API. ### Source excerpt The Netflix API evolution is a saga worth exploring, spanning 15 years and five generations of APIs, culminating in GraphQL adoption to meet the growing demands of its industry-leading streaming platform. Bruce Wang, Director of Product Platform Systems at Netflix, sat down with Matt DeBergalis, CTO at Apollo GraphQL, to discuss Netflix's extensive API journey and the adoption of GraphQL in an insightful fireside discussion during the GraphQL Summit 2023. ## Thoughts on Streaming Services: 2024 Edition DevFeed: [Thoughts on Streaming Services: 2024 Edition]() Original publisher: [Read original article]() Author: David Walsh Published: 2024-01-15T11:08:32Z Content type: opinion Language: en Sources: [David Walsh]() Topics: [Streaming](), [Netflix](), [amazon]() Tags: [amazon](), [media](), [netflix](), [streaming](), [theory-ideas]() ### AI overview An opinion piece assessing the 2024 streaming-services landscape. It discusses Netflix, sports-streaming costs, advertising tiers, brand changes at Max and Paramount Plus, the offerings from Apple and Amazon, content licensing, streaming hardware, and free services such as YouTube, RokuTV, and Tubi. ### Source excerpt Streaming services have revolutionized content delivery, sending linear media companies into a panic as they watch traditional cable services decay. "Cutting the cord" is a common practice these days, but the streaming landscape isn't perfect. We're a decade into streaming so I wanted to share my thoughts on the state of new media: first impressions, [...] The post Thoughts on Streaming Services: 2024 Edition appeared first on David Walsh Blog. ## incident.fm is coming soon DevFeed: [incident.fm is coming soon]() Original publisher: [Read original article]() Author: Charlie Kingston Published: 2022-10-24T00:00:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [incident management](), [site-reliability-engineering](), [SRE](), [Netflix](), [Deployment]() Tags: [deployment](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [netflix](), [outage](), [podcast](), [post-mortem](), [site-reliability](), [slack-incident](), [sre]() ### AI overview The article announces incident.fm, a podcast launching on YouTube and podcast apps. It previews conversations about team building, a zero-bugs policy, deploying incident.io at Netflix, and scaling a company without a clear roadmap. ### Source excerpt We've made a podcast, and we're excited to share it with you later this week... ## Apollo Federation enables parallel development across teams through a unified GraphQL graph DevFeed: [Apollo Federation enables parallel development across teams through a unified GraphQL graph]() Original publisher: [Read original article]() Author: Matt DeBergalis Published: 2021-04-06T07:28:53Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Server](), [Netflix](), [Databases]() Tags: [announcement](), [apollo-federation](), [distributed](), [gateway](), [graphql](), [netflix](), [product-engineering](), [schema](), [server]() ### AI overview The article explains how Apollo Federation lets service and domain teams own parts of a GraphQL schema while contributing to a unified graph. It describes Apollo Gateway and Managed Federation as tools for distributed architectures, schema deployment, composition integrity checks, and parallel development across teams. ### Source excerpt Building software for the internet in 2021 is hard. It's no longer just HTML, CSS, and JavaScript. We now have to deliver our products beyond just websites to mobile, voice, in-store, chat, TV, and more--while integrating data from many services and delivering on time. One of the biggest things that slow down developers is waiting to align work with other teams. It is common to get blocked while waiting to coordinate or waiting for their backlog to free up. [Next page]()