At the time I recorded this, YouTube Studio was down—and that gave me a rare chance to peek under the hood in a way you can’t when everything is healthy. I hit “Retry” in Studio, watched the network calls, and the weird part is: the API was returning HTTP 200 even though the request was clearly failing and the UI was showing “oops something went wrong.” This is exactly the kind of real-world example that maps to what I said in my backend API design video: sometimes teams intentionally “disrespect” status codes and standard semantics to reduce states and simplify clients—especially when the consumer is a tightly-controlled internal client. From there, I zoom out into the system design angle: why YouTube as a platform can keep playing videos while Studio is down. The answer is separation—deploying services independently, isolating compute, and minimizing shared central dependencies (usually databases). Video streaming/CDN, recommendations, comments, and metadata are different systems with different priorities and redundancy strategies, and the platform will often prioritize “video plays” over “everything else loads.” The takeaway isn’t “never use status codes”; it’s that as a systems engineer, your job is uptime and predictable behavior, and sometimes that means making tradeoffs that reduce edge cases—even if it annoys people in comment sections.