[rickreynoldssf]

I'm pretty sure its because the servers that host the video are just dumb servers that will serve whatever is asked. The logic is in the player. The servers don't know when you started the video watch session. If the servers had the logic and access to your state they wouldn't be able to handle as many concurrent requests.

[agilob]

but it sounds like something like istio and redis should be able to solve

[lazide]

Those are 100x (or more) more expensive than what YouTube’s backend is doing.

To do what they do affordably, there are tons of caching layers and videos are chunked into smaller opaque chunks of write-once/read-many data which get so widely distributed your head would spin.

The client code is what stitches those blocks together (and figures out what blocks are part of what), figures out what ads should be where, etc.

Any sort of consistent backend state gets very expensive fast, is often a huge bottleneck, and is avoided whenever possible.

Everything from view stats to metadata is usually even done via CRDT type eventually consistent replicated data to avoid all the bottlenecks other approaches would cause.

[creatonez]

It would be interesting to know what the upper bound on cost for a draconian anti-adblock measure would be, taking into consideration revenue from successfully killing all ad blocking. My guess is that it's not currently worth it. People have speculated on the use of Web Integrity API but at the moment, too many things have to go right for this type of DRM to even work properly, so it may kill support for way too many devices too soon.

[lazide]

I’m guessing a bunch of SWE time has been burnt doing analysis already over at YouTube. I’m also curious.

War of attrition this one is.

[jen20]

Based on my own experiments, I'm not really convinced that Istio would scale to YouTube traffic levels, though would be interested to learn otherwise.

[mdale]

I second that :)