Netflix places Open Connect appliances inside ISP networks and pre-positions content onto them during off-peak hours. Why is this fundamentally different from a conventional pull-through CDN, and what does it require from the content catalogue?

The conventional CDN model and its limits

A pull-through CDN caches on demand: the first request for an object at an edge location is a miss, fetched from origin and stored. This works because popularity is concentrated — a small number of objects serve most requests, so a modest cache achieves a high hit rate.

For long-form video this model degrades badly:

• The objects are enormous. A film in several bitrates and codecs is tens of gigabytes, so a miss is not a small latency penalty; it is a large transfer competing with live traffic.
• The catalogue is large relative to any cache, and the tail matters, because the user who wants a niche title wants it now.
• Misses happen at peak. Demand is concentrated in evening hours, so the pull-through model fetches from origin exactly when the network is most congested — the worst possible time.

What pre-positioning changes

Open Connect appliances are placed inside ISP networks and at internet exchanges, and content is pushed to them during off-peak hours, based on predicted demand for that specific location.

The consequences are structural rather than incremental:

• Peak-hour origin traffic approaches zero. During the busy evening window, the appliance serves everything it holds and fetches nothing.
• The transfer is moved to a time when capacity is free, which is a pure efficiency gain for both parties — this is why ISPs host the appliances.
• Traffic never crosses transit links during peak, so the ISP's costs fall and the viewer's path shortens to a few hops.
• Performance becomes predictable, since it no longer depends on a cache-miss lottery.

What it requires from the catalogue

Predictability. Pre-positioning works because what people will watch tomorrow is largely knowable today — catalogue popularity is stable, new releases are scheduled, and regional preferences are measurable. The fill plan is a forecasting problem with an accessible answer.

It also requires content that exists in advance. This is the critical boundary, and it is why live events are a different architecture entirely: the segments do not exist until seconds before they are requested, so nothing about them can be pre-positioned. For live, only the manifests, player assets, keys and artwork can be pushed in advance, and the segment path must be engineered as a real-time distribution tree with origin shielding and multi-CDN redundancy.

The generalisable principle

When the working set is predictable and the objects are large, pushing beats pulling. The same reasoning justifies pre-warming caches before a known traffic event, shipping ML models to inference nodes ahead of a release, and distributing configuration to edge locations before it is needed — the common structure is converting an unpredictable peak-time fetch into a scheduled off-peak transfer.