How to design a highly scalable Video Streaming Service (Netflix/YouTube) - System Design Deep Dive

Unpacking the Staggering Scale of Global Video Streaming Welcome to the Deep dive. Today we are pulling back the curtain on something that is just an incredible, almost invisible feat of modern engineering global video streaming. Speaker 2 It really is. Speaker 1 I mean, think about it, you hit play on your TV, your phone, whatever, and instantly this ultra high definition 4K video just starts flowing. Florida State and it could be coming from halfway across the globe. Speaker 2 It's the kind of infrastructure we all absolutely rely on every single day. But we never see it. You never even think about the you know, the the complex journey that one video file takes exactly. Or just the sheer mathematical scale behind making that instant playback even possible. Speaker 1 It's so easy to take for granted. We're not talking about sending an e-mail or, you know, load in a simple web page, not even cost. We're talking about petabytes of data, right? Rich, time sensitive data moving across continents, serving hundreds of millions of people who are very often watching the exact same thing at the exact same time. Speaker 2 And that's the key, that time sensitive part, video streaming is fundamentally different from say standard web infrastructure. How so? Well you're dealing with these immense data drives. We're talking multi GB files and they have to be available everywhere globally with almost 0 latency, all while adapting to the, let's face it, complete chaos of consumer Internet connections. Speaker 1 And the measure of success, the only thing that matters to the user, is simple. It has to start instantly. And there can be 0 interruptions, right? You expect perfection whether you're on, you know, super fast fiber optic or sketchy 4G on a moving train. Speaker 2 And that expectation isn't just a goal for the engineers, it's the absolute constraint that drives every single architectural choice they make. Speaker 1 From the very beginning. Speaker 2 From the moment a file is uploaded to the final second, it's delivered to your screen. The entire system, top to bottom, is built to eliminate one thing. Speaker 1 The dreaded buffering wheel. Speaker 2 The mortal enemy. Speaker 1 OK, let's unpack this complicated challenge. We have an expert guide with us who specializes in building these massively distributed video platforms. You can walk us through the engineering genius that makes this all happen. Speaker 2 Happy to. We're going to basically dissect the three key components. First the upload pipeline, how the video gets into the system, then the encoding and transcoding factory which is where all the heavy lifting. Speaker 1 Happens and finally. Speaker 2 And finally, the last layer, which is global delivery. That's where we get into things like content delivery networks and these really clever adaptive streaming protocols. The goal is for you to understand not just what happens, but why it's designed this way. It's all a necessary series of technological trade-offs. Speaker 1 All right, let's start at the beginning then the scale. We have to define what Massive really means here. We do because the platforms we're talking about, the Netflix is the Youtubes, the global video giants. The scale is just, it's staggering. It's not a website handling a few 1000 clicks. Speaker 2 No, you're dealing with problems of physics at a global scale. The very first step in designing one of these systems is to just try and internalize that scale. What? Speaker 1 Are we talking about? Speaker 2 You're planning for a worldwide user base that easily tops 100 million daily active users. But you know, the real pressure point, The thing that keeps engineers up at night, is peak usage. Speaker 1 That moment when a new season of a huge show drops or a major global event like a World Cup final kicks off. Speaker 2 Precisely. Your peak concurrency can easily hit 10 million viewers, 10 million people, all pulling down high beat rate streams at the exact same second. Wow. And that's just the output side. You have to think about the input too. If you're a platform with user generated content, you could be seeing up to 1,000,000 new videos uploaded. Speaker 1 Per day. 1,000,000 new videos a day. And these aren't just tiny little clips, I imagine. Speaker 2 Right. If we take a conservative average, say 500 megabytes per video, that instantly translates to 500 terabytes of raw content uploaded every single day. Speaker 1 That's hard to even picture. Speaker 2 And over a year, you're rapidly approaching 200 petabytes of raw storage. And that's just for the original files people uploaded. We haven't even touched the massive, complex processing that happens downstream. Speaker 1 OK, let's get to the real cost center then. How much bandwidth does all this actually use when people start streaming it the. Speaker 2 Egress traffic, so the data leaving the system and going out to users. That is the single largest operating expense for any major video platform, full stop. By a lot, by a huge margin. At peak times, these systems might be handling 1,000,000 streaming requests per second. Speaker 1 A million per second. Speaker 2 That traffic load is immense. It's measured in petabytes of data leaving the servers every day. It's a constant battle against the physics of data transport and, frankly, the cost. Understanding Core Challenges and Video Streaming Fundamentals So we've got the scale down, but let's get to the concept. Why is video streaming just inherently harder than, say, delivering a huge high resolution photo or a big PDF file? Speaker 2 Yeah, that's a great question. Speaker 1 Specifically, why is 4K streaming like 10 times harder than standard HD? Speaker 2 The problem with video is that it's time sensitive data. A photo can load completely and then you see it. It's OK if it takes 2 seconds. Video has to be a continuous, uninterrupted delivery over time, and the volume of that data is immense. 4K isn't just a slightly higher resolution than HD, it's an exponential potential jump in the density of the data. Speaker 1 Which means you run into these huge architectural challenges right away. Speaker 2 We can basically break them down into a few key areas. First is what we call large blobs in reliability. You have to upload these gigantic files, sometimes multi GB files, reliably across shaky, unpredictable global networks. Speaker 1 And it has to be resumable I'm guessing. Speaker 2 It must be resumable. You just can't hope a single connection from a phone in a rural area survives A5 hour upload. It won't. Speaker 1 OK. So that's challenge one. Speaker 2 2nd, and this is huge, is encoding. The raw videos people upload are basically useless to a global streaming system. They have to be converted or transcoded into dozens of standardized optimized versions for every possible device and every possible bandwidth condition. This is where the computational cost just skyrockets. Speaker 1 Now there's the speed. Speaker 2 Exactly. Third is delivery and latency, and the performance requirements here are incredibly strict. Video startup time has to be less than two seconds. Speaker 1 So from Click to 1st frame under 2 seconds, yes. Speaker 2 And the midstream buffering ratio has to be less than 1% and that's a global target. Speaker 1 Let's clarify that difference. Latency is the startup time, buffering is the interruption midstream. Speaker 2 Precisely. High latency means a slow start, which people hate. A high buffering ratio means a poor experience, which they hate even more. Speaker 1 What's next? Speaker 2 4th is arguably the most ingenious part of the whole system, adaptive streaming. The system has to dynamically, automatically adjust the video quality, the resolution, the compression based entirely on your current network bandwidth from moment to moment without you ever touching a thing. Speaker 1 And finally, I assume cost and security. Speaker 2 Absolutely. The fifth challenge is just dealing with the immense cost of that egress bandwidth and all that storage, and at the same time protecting that very valuable content with something called digital rights management or DRM. Speaker 1 OK, let's dive a little deeper into the tech that makes this work. We hear terms like codec and container all the time. What are they and why do they matter so much here? Speaker 2 OK, so the codec that stands for Compressor Decompressor is the algorithm. It's the magic that achieves this massive reduction in file size that you need for streaming while trying to keep the quality as high as possible. Speaker 1 Without good compression, this whole thing falls apart. Speaker 2 It would be physically impossible for most people. We're talking about standards like H264 which is everywhere for compatibility, H265 which is much better for 4K, and the newer 1 AV one which is this really efficient open source codec in the container. The container is just the wrapper. It's the file format, like MP4 or MOV. It holds the compressed video from the Kodak, the audio tracks, the subtitles, all the metadata, all packaged up together. And since different devices support different codecs and containers, the system has to produce versions for everything. An iPhone, an Android TV, a game console, you name it. Speaker 1 And all of this complexity is really driven by one simple metric, right? The by trade. Speaker 2 Exactly. By trade it's measured in megabits per second, or Mbps. It's just the amount of data being transmitted over time. Speaker 1 So a 4K stream needs. Speaker 2 It needs a sustained, reliable 10 megabits per second, maybe even up to 20 for really premium quality. HD might only need 5. So the reason 4K is exponentially harder is you're pushing a much, much higher buy trade that requires exponentially more bandwidth and processing power at every single stage of the journey. Speaker 1 So it's not just making the picture bigger. Speaker 2 No, it's about jamming 4 times the information through the same size pipe instantly and continuously, and that sets the stage perfectly for how they manage that very first step, getting the file into the system. Building a Reliable Upload Pipeline with Chunking and Deduplication Let's follow that huge video file then from the moment a user hits the upload button. As you said, global networks are unreliable, especially for these multi GB files. If I try to upload A5 GB video over my cell phone, network failure is it's almost a certainty. Speaker 2 And if that upload fails, the user experience is just ruined. They have to start the whole thing over. They've wasted hours of their time, wasted all that bandwidth. So the system absolutely must support resumable uploads. Speaker 1 OK, so how do you do that without making the user sit there and watch their connection like a hawk? Speaker 2 This is solved by what's called the chunked upload strategy. It's a really fundamental pattern for handling these large blobs of data reliably. The client application, so your app or your browser. It doesn't try to send the entire file in one go. Speaker 1 It breaks it up first. Speaker 2 It processes the file locally 1st and breaks it down into small, manageable chunks. We're typically talking 5 to 10 megabytes each. Speaker 1 And I assume each chunk is unique and you can track it somehow. Speaker 2 Yes, absolutely. Each chunk gets a unique identifier and critically A fingerprint hash. This hash does two things, it's the chunks address and it's also an integrity check so the client uploads these little chunks in parallel. Speaker 1 So if the network drops. Speaker 2 The system knows precisely which chunks made it and which ones failed just by checking the list of hashes. The client can then resume by only resending the chunks that are missing. Speaker 1 That seems like a massive improvement. But wait, if you have 10 million people watching and a million videos being uploaded, it's millions and millions of these little chunks flowing into the system. Doesn't that just completely crushed the main application servers, the ones handling all the normal requests? Speaker 2 It absolutely would, which is why the main application servers are intentionally bypassed for the actual heavy data transfer. This is a crucial cost optimization technique direct to storage upload. Speaker 1 OK, that immediately raises a huge Security question for me. If I'm the client, how can I upload my data directly to the platforms, you know high security cloud storage without going through the server that's supposed to authenticate me? Speaker 2 It's a really beautiful and simple three-step security dance. Step one, the client starts by talking to the secure API gateway, the upload service. It just identifies itself and says hey I've got 100 chunks to upload. OK. Step 2. The server validates the user's identity and then it generates a whole batch of what are called pre sign URLs, one for each chunk. Speaker 1 Pre signed URL? What's that? Speaker 2 Think of it like a secure temporary token. It's time limited, maybe it's only valid for an hour and it grants permission only to the client that requested it to do 1 specific action like upload data to one specific location in the object storage like Amazon 3 or Google Cloud Storage. Speaker 1 O the client uses that temporary key that URL to upload the chunks directly to the back end storage, completely bypassing the expensive application servers. Speaker 2 Exactly. The application servers just manage the security handshake and the metadata. They don't touch the massive data transfer itself. Once all the chunks are successfully uploaded, the client sends one final completion signal to the API. It just says I'm done. All 100 chunks are there. Please assemble. Speaker 1 And that final signal is obviously critical. How does the system then confirm that the file it just assembled is, you know, correct that it's not corrupted? Speaker 2 That's when the post upload processing flow kicks in. First is validation. The system does a cryptographic check against all those chunk hashes to make sure the file wasn't tampered with or corrupted during the transfer. Second is security standing, looking for viruses or malware. Third is metadata extraction. It analyzes the raw file to grab things like the video's duration, the resolution, the original codec, all that critical data. Speaker 1 And then the baton gets passed to the next stage, right? Speaker 2 The object storage system, once the file is validated, emits an event notification. It's basically a message that gets put onto a queue, and that message triggers the really complex downstream encoding service. This is a critical asynchronous step. The user doesn't wait for any of this, it all just runs in the background. Speaker 1 That sounds like an enormous single point of failure though. What if that message queue or the notification system goes down? Do millions of uploads just sit there unencoded? How do you build redundancy into that trigger? Speaker 2 That's a vital architectural question. You never, ever rely on a single queue. These systems use highly durable distributed messaging systems, things like Kafka or Amazon's SQS, with strict redundancy across multiple physical data centers. Speaker 1 So there's a backup. Speaker 2 There's more than a backup. The upload service itself also keeps a record in a database tracking which uploads have finished but haven't been encoded yet. So if the primary notification somehow fails, a separate scheduled job, often called a reconciliation service, periodically scans that database to find and re trigger any uploads that got stuck. Availability is everything. Speaker 1 Let's go back to cost for a second. Can the system detect if the exact same video file has been uploaded twice, maybe by two different people, to save on all that storage? Speaker 2 Oh absolutely. D duplication is a massive cost saving measure, especially on platforms with user generated content where you see the same memes or movie clips being uploaded over and over. How does it work? By using those same chunk hashes from the upload phase, the system can compute a unique signature for the entire file. So if user A uploads a video and then user B uploads the identical video an hour later, the system compares those overall signatures. Speaker 1 And if they match? Speaker 2 If they match, user B's upload is marked as successful, but the actual data isn't stored again. Instead, a new metadata entry is created that just points to the data that user A already stored. Speaker 1 So you save bandwidth, you save processing, and you save storage just by being smart about hashing the content. That kind of optimization must be essential when you're dealing with 200 petabytes a year. Speaker 2 It's not optional, it's the only way to survive at that scale. Inside the Transcoding Factory: Processing, Encryption, and DRM OK, so the file has been validated, it's secure, and that notification has triggered the next stage. This is the heart of the operation, right? The transcoding factory. This is where one single input file gets turned into what potentially hundreds of output files for streaming. Speaker 2 Computationally, this is by far the most demanding part of the entire pipeline. This is where you bring out the massive server farms, often with specialized hardware like GPU's to just crunch numbers. Speaker 1 Why can't we skip this step? I mean, why not just store the user's original high quality file, even if it's 4K and just serve that? Speaker 2 We can't for three really critical reasons. The 1st is format compatibility. Like we said, every device needs different codecs and containers. If you just serve the users raw MOV file, you'd probably exclude half the world's devices from being able to play it. Speaker 1 OK. And the second. Speaker 2 2nd, and this is the most crucial 1 is adaptive streaming. To prevent that buffering wheel, we have to be able to dynamically switch the quality, and to do that you have to create multiple versions ahead of time. You take that 4K input and you generate 1080P720P480P all the way down to a 240P version, all indexed and ready to go. Speaker 1 And the third reason? Speaker 2 Optimization. The raw uploaded file is usually huge and not very efficiently compressed. We re encode it using the absolute state-of-the-art codecs with really careful settings like multi pass encoding to get the maximum quality at the lowest possible byte rate. That saves a fortune on egress costs later. Speaker 1 Multi pass encoding? That sounds complicated. Is that where the system actually like watches the video before it encodes it? Speaker 2 That's a great way to think about it, yes. In a simple single pass encode, the server just blindly applies compression. But in multi pass, usually 2 pass, the first pass analyzes the entire video. It looks for complex scenes like a big action sequence or water effects, versus simple scenes like a static shot of someone talking. Speaker 1 And then the second pass uses that information. Speaker 2 The second pass then intelligently allocates more bits to those complex, hard to compress scenes and fewer bits to the simple ones. The result is a much higher quality video for the same file size. Speaker 1 O1 video becomes 20, maybe 30 different versions, each one tailored for a specific network condition. How do you organize a computational task that massive? Speaker 2 It's structured as a very complex directed a cyclic graph or DAG. The easiest way to think of a DAG is like a flow chart where every box is a task and the arrows define what has to happen before something else can start. Speaker 1 OK, so what's the first step in that DAG? Speaker 2 The first step is splitting. The original big video file is first divided into small playable segments. These are typically just two to 10 seconds long, and these are not the upload chunks. To be clear, these are the chunks the final video player on your device will actually request. Speaker 1 Why so short? 2 to 10 seconds seems really small. Speaker 2 That short duration is the secret sauce for fast adaptation. If your network suddenly slows down, the player only needs to finish playing the current tiny segment before it can switch to a lower quality stream for the next one. If the segments were, say, a minute long, you could be stuck buffering for 58 seconds before the system could react. Speaker 1 Ah I see. So what's next in the DAG after splitting? Speaker 2 Step 2 is parallel transcode. This is where the magic really happens. Every single one of those little 2 to 10 second segments is sent out to a massive distributed pool of worker servers, and they're all transcoded simultaneously into every required format and resolution. Speaker 1 So 1 chunk becomes 20 chunks all at once. Speaker 2 Exactly. The 4K segments are encoded using H265, the 1080P ones might use H264 for better compatibility and so on. All happening in parallel. Speaker 1 This must be incredibly expensive. Are these video platforms using standard CPU's for this or are they on specialized? Speaker 2 Hardware. They use both and they choose based on priority and cost. CPU based encoding is often cheaper for low priority high volume stuff, but it's slow for high priority content, especially 4K. They use specialized hardware like high end GPU's or even custom built ships. ASICS GPU acceleration can drastically cut down the encoding time. Speaker 1 How much faster? Speaker 2 You can often achieve real time or even faster than real time encoding, but it comes at a significantly higher cost per minute. Speaker 1 And what else is happening in that DAG at the same time? It can't just be the video. Speaker 2 No. The beauty of the DAG is that you can run all sorts of things in parallel. Tasks like generating static thumbnails and those little preview images you see when you scrub the time, subtitle processing where caption files are extracted and synced, or handling multiple audio tracks for different languages and surround sound and security has. Speaker 1 To be in there somewhere. Where does digital Rights management, the DRM, fit into this process? DRM is integrated. Speaker 2 Right into the encoding pipeline. As soon as those little segments are transcoded, they are immediately encrypted using specialized keys. They're not stored as plain video, they're stored as scrambled encrypted data. So how does? Speaker 1 My device play it when you go to play the. Speaker 2 Video your device has to 1st talk to a completely separate license server and only if your account is authenticated and authorized does that license server send a decryption key to your player. So the key take. Speaker 1 Away is that the content is encrypted when it's stored, but the key to unlock it is only delivered at the moment of playback, exactly the. Speaker 2 Content Delivery Network. The CDN. It only ever holds the encrypted segments, it never has the key. This protects the content even if an edge server at the CDN were somehow compromised. OK, so after all that. Speaker 1 Work. You have hundreds of these short encrypted multi resolution segments. How does my device, my player, know which one to ask for at any given moment, that is? Speaker 2 The job of the final crucial output of this whole factory the manifest file. It's basically the index file. The system only generates this tiny text file after every single segment has been successfully transcoded and stored, and this file. Speaker 1 Is like the instruction manual for my video player. It's the perfect. Speaker 2 Analogy. It lists every available format for that video. For example, it'll say here's the 4K version at 15 megabits per second, here's the 1080P version at 5 megabits per second. And for each one it provides the precise URL for every single segment chunk and this has to follow. Speaker 1 Industry standards, I assume. Oh yeah. Speaker 2 We rely on standard adaptive streaming protocols. The main 2 are HLS which is HTTP Live Streaming and it uses M3U8 manifest files. The other is DAS Dynamic Adaptive Streaming over HTTP which uses MPD manifest files. So the final product. Speaker 1 Of this entire massive encoding factory is just hundreds of small encrypted video files and this one tiny critical map file. That's it. Speaker 2 All now sitting in durable cloud storage, ready for the final step, global delivery. How CDNs and Adaptive Streaming Deliver Seamless Global Video We've built this. Speaker 1 Incredible parallelized factory. But now we have the ultimate scaling challenge, scaling the reeds. A video was processed once, but it might be watched millions of times. If everyone in Europe tries to access a video that's stored in a single data center in the US, the latency, the lag would make it unwatchable, impossible. Speaker 2 And this challenge is addressed by the Content Delivery Network, or CDN. The CDN is this distributed engine that's designed to do one thing, place content as physically close to you, the end user as possible. Without it, streaming at scale would simply collapse. So describe what the. Speaker 1 CDN's architecture looks like in this system it's a massive. Speaker 2 Global network of high speed servers. They're called edge servers or cache locations. When a video, or more accurately it's little two to 10 second segments and its manifest file becomes popular, the CDN pulls that hot content from the central storage and catches it at these edge locations all over the world. So that means when I. Speaker 1 Click Play in Singapore. The data isn't flying halfway across the globe from a server in, say, Virginia, correct? It's traveling. Speaker 2 A significantly shorter distance from a regional edge server, maybe just a few miles away. And that's how we reduce the latency from hundreds of milliseconds down to maybe 10s of milliseconds. It dramatically cuts down the startup time, and it's vital for handling that 1,000,000 requests per second peak traffic. It insulates the back. Speaker 1 End from all that read traffic completely. Speaker 2 All right, let's get to the moment. Speaker 1 Of truth the adaptive by treat streaming or ABS in action, I click play. What exact steps does my device take to give me that seamless experience? It's an active. Speaker 2 Continuous negotiation step one. Your device fetches the video's metadata and that gives it the URL to the manifest file, which is probably sitting in that nearest CDN edge server, so it gets the map 1st. Speaker 1 It gets the map Step 2. Speaker 2 The client downloads that manifest file. This file is the entire menu of options. It lists everything from the 4K stream at 15 all the way down to a grainy 240P stream at half a megabit per second. Step three initial bandwidth assessment. The player on your device instantly checks your current network speed and your device's capability. It doesn't guess. It runs really quick throughput checks. Then it starts by requesting that first two second segment at the highest quality it thinks your network can reliably support. And the real genius. Speaker 1 Is what happens while that first little segment is playing. Yes, the. Speaker 2 Client is continuously monitoring 2 critical things while it's playing your network throughput and more importantly your buffer occupancy. Buffer occupancy. Speaker 1 Yeah, that's just. Speaker 2 How much future video measured in seconds the client currently has stored in its local memory? OK, that makes sense. So. Speaker 1 If my buffer starts to shrink, it means my network isn't keeping up no matter what the speed test said a second ago. Exactly right. Speaker 2 Most modern adaptive algorithms prioritize maintaining a healthy buffer level. So if the client sees that buffer syncing, say it drops below 15 seconds of queued up video, it immediately uses the manifest file to switch its request for the very next segment to a lower by trade version. It makes that. Speaker 1 Critical trade off. It chooses to keep the video flowing over maintaining maximum quality. It'll dynamically drop from 4K to 1080P for the next chunk if it has to, and that is the. Speaker 2 Buffer killer. Because the segments are so short and the monitoring is continuous, the players queue never runs dry. It can fluidly switch quality up or down without ever interrupting the playback. Then if you walk back into a good Wi-Fi zone, your throughput goes up, your buffer grows, and the system scales the quality right back up in the next segment request. So the application. Speaker 1 On my phone or TV is actually a critical thinking engine. It's managing the quality based on this constant real time feedback, and its number one priority is protecting the buffer you're empowering. Speaker 2 The user device to be the ultimate decision maker on quality. It ensures that the main objective, uninterrupted playback is met no matter what the network limitations are. And it's. Speaker 1 Just as critical to scale the metadata as it is the video itself, right? I'm talking about the titles, the descriptions, and especially the URLs that point to those all important manifest files. We're still talking about a million requests per second, just to look that stuff up. You. Absolutely. Speaker 2 Cannot handle that read volume with a single database. It would melt. To scale metadata, these platforms rely on specialized distributed database architectures like Cassandra or highly partitioned relational databases. What does? Speaker 1 Partitioned mean here it just means the data. Speaker 2 Is spread across hundreds of machines, often organized by the videos ID or something similar. This spreads the load out, but even though systems can't handle the peak traffic on their own. So that brings us to. Speaker 1 Aggressive caching, Yes, you place. Speaker 2 These high speed, ultra low latency in memory caches like Redis right in front of the database. These caches store the metadata for all the hot content the popular shows that millions are watching at the same time. This caching layer can insulate the main database from 95% or more of that peak traffic. It's a multi layer defense strategy all focused on read performance. The Ultimate Trade-off: Availability Through Graceful Degradation So what does this all? Speaker 1 Mean we've traced this incredible journey of a single 4K file. It starts with a secure chunked resumable upload using pre signed URLs, right. Then it goes through this complex decentralized encoding engine that creates hundreds of short encrypted segments, all indexed by. Speaker 2 That manifest file indexed by a manifest file. Speaker 1 File distributed globally by a CDN, which then delivers the content instantly by having this continuous negotiation with your device the entire system. Speaker 2 Is just a decentralized engine built on redundancy, compression, distribution and critical thinking. The complexity is hidden in all these little details. The two pass encoding for efficiency, using short segments for rapid adaptation, and that client side decision making that always prioritizes the buffer. It really is a phenomenal. Speaker 1 Adaptive feat of engineering that's just constantly running in the background, making physics yield to our entertainment to really. Speaker 2 Grasp the final terrifying scale of it all. Consider this one last thought. It's rooted in fault tolerance. The capacity estimation for just 190 minute 4K live stream, let's say a World Cup final watched by 10 million concurrent users, requires roughly 1.25 petabytes of data transfer just to the CDN during that event. That's managed in real. Speaker 1 Time in real time, so. Speaker 2 What happens when concurrent demand pushes way past that 10 million viewer mark and the CDN itself starts to feel the strain? The system has to be prepared. Speaker 1 For catastrophic success, that's where the final. Speaker 2 Architectural layer kicks in graceful degradation. If the load balancers and the CDN edge servers are just absolutely saturated, the system won't just fail and show you a blank screen. Instead, as a last resort, the CDN or the streaming server is configured to start denying requests for the highest bytrate manifest files, so chooses the path. Speaker 1 Of least resistance it tells your. Speaker 2 Player, sorry, you can only access the 720P or maybe the 480P streams right now. It sacrifices quality to preserve flow and availability for everyone. This guarantees that all 10 million viewers see the action instantly, even if a fraction of them see it at a slightly lower resolution. It is the ultimate trade off, putting availability over instantaneous perfection.