[nicce]

Yes, but it is still counts only a fraction of the purpose of their infrastructure. There are no hard global real-time sync requirements.

> When you're watching a movie your progress is constantly updated, posting data

This can be implemented on server side and with read requests only.

A proper comparison would be YouTube where people upload videos and comment stuff in real-time.

[TZubiri]

There's many cases where server side takes you 98% there, but it still makes economical sense to spend shitloads on getting that 2% there.

In this case it's not the same whether your server sends a 10 second packet and the viewer views all of it, and whether server sends a 10 second packet, but client pauses at the 5s mark (which needs client-side logic)

Might sound trivial, but at netflix scale there's guaranteed a developer dedicated to that, probably a team, and maybe even a department.

[PittleyDunkin]

> A proper comparison would be YouTube where people upload videos and comment stuff in real-time.

Even in this one sentence you're conflating two types of interaction. Surely downloading videos is yet a third, and possibly the rest of the assets on the site a fourth.

Why not just say the exact problem you think is worth of discussion with your full chest if you so clearly have one in mind?

[TZubiri]

I'd make a distinction on:

-the entropy of the data: a video is orders of magnitude than browsing metadata.

- the compute required: other than an ML algorithm optimizing for engagement, there's no computationally intensive business domain work (throughput related challenges dont count)

- finally programming complexity, in terms of business domain, is not there.

I mean my main argument is that a video provider is a simple business requirement. Sure you can make something simple at huge scale and that is a challenge. Granted.