Content Pre-Positioning

Conventional edge caching is reactive: the first request for an object at a location is a miss, served from origin and then cached. This is efficient when objects are small and popularity is concentrated, because the miss cost is a modest latency penalty paid once.

Pre-positioning inverts the direction. Demand for each location is forecast, and the content is pushed there in advance — typically during off-peak hours — so that the busy period is served entirely from local storage with near-zero origin traffic.

Why it matters

For large objects the reactive model fails on three counts at once. A miss is a large transfer, not a small delay. Misses occur at peak, because that is when requests arrive, so the origin fetch competes with the traffic it is meant to serve. And the long tail matters, because the user requesting an unpopular item wants it immediately and a cache sized for the head does not help them.

The economic argument is what makes the pattern deployable: moving transfer to off-peak hours is a benefit to the network operator as well as to the content provider. Off-peak capacity is otherwise wasted, peak transit is expensive, and the shorter path improves the end-user experience. That alignment is why network operators host such appliances at their own expense.

Implementation patterns

• Per-location demand forecasting from historical viewing, regional preference, scheduled releases and recommendation-system outputs — the fill plan is a prediction problem, and it is a tractable one.
• Off-peak fill windows derived from each location's own traffic curve rather than a global schedule.
• Tiered fill: the most confident predictions to every location, the long tail to a smaller number of regional caches that nearby locations can reach without touching origin.
• Storage-aware eviction that accounts for what is scheduled to arrive, not just what is currently popular.
• Pre-warming before known events — a release, a sale, a scheduled broadcast — as a deliberate operation with its own checklist.
• Measuring fill efficiency: the fraction of pushed bytes actually served. A pre-positioning system with poor prediction is bandwidth spent on nothing, and this metric is the one that keeps it honest.
• A fallback to pull-through for genuine misses, since prediction is never complete.

Industry example

Netflix's Open Connect places appliances inside ISP networks and at internet exchanges, filling them during off-peak hours according to predicted regional demand. During peak evening hours the appliances serve from local storage and fetch essentially nothing, so traffic does not cross transit links at the moment they are most congested.

The boundary of the technique is equally instructive. Live events cannot be pre-positioned, because the segments do not exist until seconds before they are requested. For live, only manifests, player code, 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 — a completely different architecture that happens to share a delivery network.

Failure scenarios

• Poor prediction, filling caches with content nobody requests while the popular items miss.
• Fill traffic overlapping peak, so the mechanism intended to reduce peak load contributes to it.
• Storage exhaustion from over-eager filling, evicting content that is about to be requested.
• Treating live content as pre-positionable, which does not work and is a category error rather than a tuning problem.
• No pull-through fallback, so an unpredicted request fails rather than being served slowly.
• Stale content served after an update or takedown, because pushed content has no natural expiry — invalidation must be an explicit, reliable mechanism.
• Fill efficiency never measured, so a degrading prediction model goes unnoticed for months.

Trade-offs

Pre-positioning spends bandwidth and storage on content that may not be requested, which is a real cost that reactive caching does not incur. It also requires substantial storage at every location — enough to hold a meaningful fraction of the catalogue — and a forecasting capability that must be built and maintained.

It is therefore worthwhile only when demand is predictable, objects are large, and peak concentration is severe. For small objects with unpredictable access — API responses, user-specific data, a long tail of one-off requests — reactive caching is strictly better and pre-positioning would be waste.

The trade is off-peak bandwidth and storage in exchange for peak capacity and predictable performance, and it pays when peak capacity is the scarce resource. In a system where peak is comfortable, the pattern buys nothing.

Interview question

"We serve large video files and our origin melts every evening at 8pm. Design a pre-positioning system, tell me what metric proves it is working, and tell me why the same approach cannot save us during a live event."