3 ms·

Every time you like/dislike/watchlist a movie you're posting data. When you're watching a movie your progress is constantly updated, posting data. Simple stuff

Every time you like/dislike/watchlist a movie you're posting data. When you're watching a movie your progress is constantly updated, posting data. Simple stuff but there's possibly hundreds of thousands of concurrent users doing that at any given moment.

nicce 2y ago
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.
- PittleyDunkin 2y ago
  > 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 2y ago
    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.
- TZubiri 2y ago
  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.

nicce 2y ago

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.

PittleyDunkin 2y ago
> 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 2y ago
  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.
TZubiri 2y ago
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.