Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Lot of mistakes in this article, afair it can't hold all the movies but just the most popular. http://oc.nflxvideo.net/docs/OpenConnect-Deployment-Guide.pd...

" Each appliance stores a portion of the catalog, which in general is less than the complete content library for a given region. Popularity changes, new titles being added to the service, and re- encoded movies are all part of the up to 7.5TB of nightly updates each cache must download to remain current. We recommend setting up a download window during off-peak hours when there is sufficient free capacity."



"But wait, you say. That'd be all fine and dandy if Netflix was etched in stone, but it's not! They add and remove stuff all the time! That's right, which is why most OCAs take a 7.5TB update. Every. Freaking. Day.

"If you had to take a 7.5TB update on your home internet, you would be screwed. According to Ookla's Net Index, the average download speed in the United States is 18.6Mbps. So with an average connection, that 7.5TB would take you about 40 days to chew through.

"Fortunately, data centers tend to have a little more speed to work with. A firehose, compared to your bendy straw. So Netflix recommends a much shorter 10-hour span (from 2AM to noon, local time) where these boxes can soak up their updates with 1.2Gbps connections. That is to say, 'Google Fiber speeds.'"

Source: TFA.


I'm sure thought has been put into it. I just wonder why the OCAs aren't caches? I'd imagine a cache you be a lot more (mostly bandwidth) efficient for the ISPs and scale much better.

I request a stream. It's proxied through the device. It's not present on the device. So the device requests the 1080P from Netflix. It transcodes the stream it receives on-the-fly and sends me whatever quality I require while writing both the original and my lower-quality version to disk.

I mean maybe the limitation in that plan is the number of streams that could be transcoded simultaneously. So maybe instead the on-the-fly version isn't cached. Because I may need to switch quality on-the-fly. So maybe instead jobs are just queued up for the 5 or so formats required based on the 1080P download and they can process on spare transcoders opportunistically.

Just interesting to think through it as a programming problem. I'm sure the people working on this are very smart. It just seems really heavy on the bandwidth utilization as is.


I can think of reasons why a pure cache would impose costs that are too high -- namely, the device would then be writing during times of very read load.

But: I agree with your bigger point, that it's an interesting programming problem.

We're all familiar with CPU caches, so it's interesting mental exercise to think of this as the same system, but optimized for a different part of design space.


Quote from the article:

"It's rarely—if ever—a full copy, but rather a massive chunk specifically designed for a specific country or region, depending on what's available and what's popular."


In addition, Netflix has multiple copies of the same content at different quality levels. So, there might be the 1080p, 720p, and SD quality levels of the popular content, each of them taking up space from other movies/shows.


Forgot about that issue. That has to be fun providing space for all of the duplication!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: