Push CDNs: When to Pre-populate Edge Caches

After this topic, you will be able to:

Describe the push CDN workflow from content upload to edge distribution
Justify when to use push CDNs based on content characteristics and traffic patterns
Evaluate trade-offs between push CDN storage costs and origin server load reduction
Compare push CDN suitability for static vs dynamic content delivery

TL;DR

Push CDNs proactively distribute content to all edge locations when you upload it, rather than waiting for user requests. You control exactly when content is deployed, paying for storage across all edges but eliminating origin server load and cache misses. Cheat Sheet: Best for infrequent updates (weekly releases), predictable content (marketing sites, documentation), and when you need guaranteed edge presence. Trade storage costs for zero origin traffic and complete deployment control.

The Analogy

Think of push CDNs like pre-stocking vending machines across a city. Before anyone asks for a snack, you drive to every machine and fill it with inventory. When customers arrive, everything is already there—no waiting, no calling back to the warehouse. You pay for the space in every machine and the gas to visit them all, but you never run out of stock and your warehouse stays quiet. Pull CDNs are like on-demand delivery: you only send products when someone orders, saving storage but requiring warehouse capacity.

Why This Matters in Interviews

Push CDNs reveal your understanding of proactive vs reactive content distribution. Interviewers use this to assess whether you can make cost-performance trade-offs: when is paying for storage across 200+ edge locations worth eliminating origin load? Can you identify workloads where predictable deployment beats on-demand caching? Senior candidates should articulate the operational complexity of managing synchronized deployments across a global edge network versus the simplicity of origin-driven pull models. This topic separates engineers who just know “CDNs cache stuff” from those who understand content distribution economics.

Core Concept

Push CDNs implement a proactive content distribution model where you explicitly upload content to the CDN provider, who then replicates it to all edge locations before any user requests arrive. Unlike pull CDNs that fetch content on-demand when cache misses occur (see Pull CDNs), push CDNs require you to take full responsibility for content lifecycle: uploading new versions, managing expiration policies, and triggering updates. This approach transforms the CDN from a reactive cache into a pre-positioned content repository. You’re essentially treating the global edge network as your primary storage layer, not just a performance optimization. The fundamental trade-off is simple: pay for storage everywhere in exchange for zero origin server involvement after initial upload.

Push CDN Storage Cost Model vs Pull CDN Bandwidth Model

graph TB
    subgraph Push CDN Cost Structure
        P_Upload["Upload 50GB Content"]
        P_Storage["Storage: 50GB × 150 edges<br/>= 7,500 GB-months<br/>Cost: $750/month fixed"]
        P_Requests["Serve 100M requests<br/>or 100 requests<br/><b>Same storage cost</b>"]
        P_Upload --> P_Storage
        P_Storage --> P_Requests
    end
    
    subgraph Pull CDN Cost Structure
        PL_Origin["Origin: 50GB Content"]
        PL_Cache["Cache on-demand<br/>at edges"]
        PL_Low["Low Traffic: 1TB transfer<br/>Cost: $80/month"]
        PL_High["High Traffic: 50TB transfer<br/>Cost: $4,000/month"]
        PL_Origin --> PL_Cache
        PL_Cache --> PL_Low
        PL_Cache --> PL_High
    end
    
    Decision{"Traffic Volume?"}
    Push["✓ Push CDN<br/>Fixed cost amortized<br/>over many requests"]
    Pull["✓ Pull CDN<br/>Pay only for<br/>actual usage"]
    
    Decision --"High traffic<br/>(>10M requests/month)"--> Push
    Decision --"Low/unpredictable traffic"--> Pull

Push CDNs charge fixed storage costs across all edges regardless of traffic, making them economical only when high request volumes amortize the storage expense. Pull CDNs charge per-request bandwidth, better for unpredictable or low-traffic scenarios.

Push vs Pull CDN Decision Framework

flowchart TB
    Start(["Content Distribution<br/>Decision"])
    
    Q1{"Update<br/>Frequency?"}
    Q2{"Traffic<br/>Predictability?"}
    Q3{"Origin<br/>Capacity?"}
    Q4{"Content<br/>Size?"}
    
    Push_Freq["✓ Push CDN<br/><b>Infrequent updates</b><br/>Daily/weekly releases<br/>Batch deployments"]
    Pull_Freq["✓ Pull CDN<br/><b>Frequent updates</b><br/>Hourly/continuous<br/>Auto-propagation"]
    
    Push_Traffic["✓ Push CDN<br/><b>Predictable high traffic</b><br/>80%+ content accessed<br/>Storage cost justified"]
    Pull_Traffic["✓ Pull CDN<br/><b>Unpredictable/low traffic</b><br/>Long-tail distribution<br/>Pay per actual use"]
    
    Push_Origin["✓ Push CDN<br/><b>Constrained origin</b><br/>Eliminate origin load<br/>No cache miss handling"]
    Pull_Origin["✓ Pull CDN<br/><b>Excess origin capacity</b><br/>Handle cache misses<br/>Avoid storage costs"]
    
    Hybrid["⚡ Hybrid Approach<br/>Push: Static assets<br/>Pull: Dynamic content"]
    
    Start --> Q1
    Q1 --"< 1x/day"--> Q2
    Q1 --"> 1x/hour"--> Pull_Freq
    
    Q2 --"Predictable"--> Push_Traffic
    Q2 --"Unpredictable"--> Q3
    
    Q3 --"Limited"--> Push_Origin
    Q3 --"Available"--> Pull_Origin
    
    Push_Traffic --> Q4
    Q4 --"< 100GB"--> Push_Freq
    Q4 --"> 1TB"--> Hybrid

Decision tree for choosing between push and pull CDNs based on update frequency, traffic patterns, origin capacity, and content size. Most real-world systems use hybrid approaches, pushing static assets while pulling dynamic content.

Push CDN Propagation Delay Problem

sequenceDiagram
    participant Dev as Developer
    participant CDN as CDN API
    participant Edge1 as Edge US (Fast)
    participant Edge2 as Edge EU (Medium)
    participant Edge3 as Edge APAC (Slow)
    participant App as Application Deploy
    participant User as End Users
    
    Note over Dev,User: ❌ WRONG: Deploy app before replication completes
    
    Dev->>CDN: Upload logo-v2.png (t=0)
    CDN->>Edge1: Replicate (completes t=5min)
    CDN->>Edge2: Replicate (completes t=20min)
    CDN->>Edge3: Replicate (completes t=45min)
    
    Note over App: App deployed at t=10min<br/>References logo-v2.png
    
    Dev->>App: Deploy new app version (t=10min)
    
    User->>Edge1: GET /logo-v2.png
    Edge1-->>User: ✓ 200 OK (file exists)
    
    User->>Edge2: GET /logo-v2.png
    Edge2-->>User: ❌ 404 Not Found (still replicating)
    
    User->>Edge3: GET /logo-v2.png
    Edge3-->>User: ❌ 404 Not Found (still replicating)
    
    Note over Dev,User: ✓ CORRECT: Wait for replication confirmation
    
    Dev->>CDN: Upload logo-v3.png (t=60min)
    CDN->>Edge1: Replicate
    CDN->>Edge2: Replicate
    CDN->>Edge3: Replicate
    
    CDN-->>Dev: Replication complete (t=105min)
    
    Dev->>App: Deploy new app version (t=110min)
    
    User->>Edge1: GET /logo-v3.png
    Edge1-->>User: ✓ 200 OK
    User->>Edge2: GET /logo-v3.png
    Edge2-->>User: ✓ 200 OK
    User->>Edge3: GET /logo-v3.png
    Edge3-->>User: ✓ 200 OK

Common pitfall: deploying application code that references new CDN assets before replication completes causes 404 errors in slower edge locations. Solution: wait for replication confirmation from CDN API before updating application references, or use versioned URLs to allow old and new content to coexist.

Netflix Open Connect Push CDN Architecture

graph TB
    subgraph Netflix Origin Infrastructure
        Catalog["Content Catalog<br/><i>New releases, metadata</i>"]
        Encoder["Encoding Pipeline<br/><i>Multiple bitrates</i>"]
        Scheduler["Push Scheduler<br/><i>Off-peak hours 2-8 AM</i>"]
    end
    
    subgraph ISP Network: Comcast
        OCA1["OCA Appliance 1<br/><i>100-200TB storage</i>"]
        OCA2["OCA Appliance 2<br/><i>100-200TB storage</i>"]
    end
    
    subgraph ISP Network: Verizon
        OCA3["OCA Appliance 3<br/><i>100-200TB storage</i>"]
        OCA4["OCA Appliance 4<br/><i>100-200TB storage</i>"]
    end
    
    subgraph ISP Network: AT&T
        OCA5["OCA Appliance N<br/><i>Thousands globally</i>"]
    end
    
    User1["Subscriber<br/><i>Streams movie</i>"]
    User2["Subscriber<br/><i>Streams TV show</i>"]
    
    Catalog --> Encoder
    Encoder --> Scheduler
    
    Scheduler --"Nightly push<br/>(2-8 AM local)"--> OCA1
    Scheduler --"Nightly push"--> OCA2
    Scheduler --"Nightly push"--> OCA3
    Scheduler --"Nightly push"--> OCA4
    Scheduler --"Nightly push"--> OCA5
    
    User1 --"100% of streams<br/>from local OCA"--> OCA1
    User2 --> OCA3
    
    Note1["Zero origin traffic<br/>during streaming<br/>All content pre-positioned"]
    Note2["Storage cost justified:<br/>Each movie watched<br/>1000s of times"]
    
    OCA1 -.-> Note1
    Scheduler -.-> Note2

Netflix Open Connect uses push CDN model to pre-position video content in ISP networks during off-peak hours. Origin servers never serve video to end users—100% of streaming traffic comes from local OCA storage. High request volumes (thousands of streams per movie) justify the massive storage costs across thousands of appliances globally.

How It Works

The push CDN workflow begins when you upload content directly to the CDN provider’s API or storage interface—this might be an S3-compatible endpoint, an rsync target, or a proprietary upload tool. The CDN’s origin infrastructure receives your content, validates it, and initiates a replication job to propagate copies to every edge location in their network. This propagation can take minutes to hours depending on content size and network topology. Once replication completes, you update your DNS or URL configuration to point to the CDN’s edge domains. When users request content, the edge server serves it directly from local storage without ever contacting your origin server. You configure TTL policies that tell the CDN when content expires, but unlike pull CDNs where TTL triggers re-fetching from origin, push CDN expiration simply marks content as stale until you explicitly upload a new version. URL rewriting is critical: your application must generate URLs pointing to the CDN’s domain (cdn.example.com/assets/v2/logo.png) rather than your origin (origin.example.com/logo.png). This gives you explicit control over which content versions are live at the edge.

Push CDN Content Distribution Workflow

graph LR
    Dev["Developer<br/><i>CI/CD Pipeline</i>"]
    API["CDN API<br/><i>Upload Endpoint</i>"]
    Origin["CDN Origin<br/><i>Validation & Processing</i>"]
    
    subgraph Global Edge Network
        Edge1["Edge US-East<br/><i>Local Storage</i>"]
        Edge2["Edge EU-West<br/><i>Local Storage</i>"]
        Edge3["Edge APAC<br/><i>Local Storage</i>"]
        EdgeN["Edge ...N<br/><i>200+ Locations</i>"]
    end
    
    User1["User<br/><i>New York</i>"]
    User2["User<br/><i>London</i>"]
    User3["User<br/><i>Tokyo</i>"]
    
    Dev --"1. Upload content<br/>(logo-v2.png)"--> API
    API --"2. Receive & validate"--> Origin
    Origin --"3a. Replicate<br/>(15-60 min)"--> Edge1
    Origin --"3b. Replicate"--> Edge2
    Origin --"3c. Replicate"--> Edge3
    Origin --"3d. Replicate"--> EdgeN
    
    User1 --"4. GET /logo-v2.png<br/>(after replication)"--> Edge1
    Edge1 --"5. Serve from<br/>local storage"--> User1
    User2 --> Edge2
    User3 --> Edge3

Push CDN workflow showing proactive content distribution. Developer uploads once to CDN API, which replicates to all edge locations globally before any user requests. Users always hit local edge storage with zero origin involvement after initial push.

Key Principles

principle: Explicit Content Lifecycle Management explanation: You control every aspect of what content exists at the edge and when it changes. There’s no automatic cache warming, no origin fallback on miss, no implicit refresh. If you don’t upload it, it doesn’t exist. This explicit model eliminates the “eventual consistency” problems of pull CDNs where different edges might have different cached versions. example: Netflix’s static asset deployment pushes new UI bundles to all CDN edges during off-peak hours. They know exactly when the new version goes live globally because they control the push timing, avoiding the gradual rollout that happens with pull CDN cache expiration.

principle: Storage-Bandwidth Trade-off explanation: Push CDNs charge primarily for storage (GB-months across all edges) rather than bandwidth (GB transferred). You pay for content to exist everywhere even if some edges never serve it. This inverts the cost model: high-traffic content becomes cheaper (fixed storage cost amortized over many requests) while low-traffic content becomes expensive (storage cost with few requests to justify it). example: A documentation site with 50GB of content across 150 edge locations pays for 7.5TB-months of storage whether it serves 100 requests or 100 million. With pull CDNs, they’d only pay for bandwidth actually consumed, making push economically inefficient for low-traffic scenarios.

principle: Zero Origin Load Post-Deployment explanation: After successful push replication, your origin server receives zero traffic for that content. Every request hits the edge. This eliminates origin capacity planning for content delivery, reduces infrastructure costs, and removes the origin as a potential failure point for static assets. example: Fastly’s push-based customer configurations allow origin servers to be completely shut down during maintenance windows. Static assets continue serving from edge storage while the origin is offline, something impossible with pull CDNs that need origin availability for cache misses.

Deep Dive

Types / Variants

Push CDNs come in two operational models: full replication where every file is pushed to every edge location globally, and selective replication where you specify geographic regions or edge tiers for each content set. Full replication maximizes availability and performance but multiplies storage costs—uploading a 1GB file to 200 edges consumes 200GB of billable storage. Selective replication reduces costs by only pushing content to edges where you expect traffic, but requires you to predict geographic demand accurately. Some providers offer lazy push models where content is pushed to a primary tier of edges immediately and secondary edges on-demand, blending push and pull characteristics. Version management varies by provider: some maintain multiple versions simultaneously (allowing instant rollback), others replace content atomically (one version at a time), and advanced systems support percentage-based rollouts where different edges serve different versions during transitions.

Trade-offs

dimension: Content Update Frequency option_a: Push CDN: Efficient for infrequent updates (daily/weekly releases). Each update triggers a global replication job, so frequent changes multiply operational overhead and propagation delays. option_b: Pull CDN: Efficient for frequent updates (hourly/continuous). Origin changes automatically propagate as caches expire, no explicit deployment needed. decision_framework: Use push if updates happen less than once per day and you need synchronized global deployment. Use pull if content changes continuously or you need instant origin-to-edge propagation.

dimension: Traffic Predictability option_a: Push CDN: Best for predictable traffic patterns where you know content will be requested. Storage costs are justified by high request volumes amortizing the fixed storage expense. option_b: Pull CDN: Best for unpredictable traffic where some content might never be requested. You only pay bandwidth costs for content actually served. decision_framework: Use push if >80% of uploaded content gets requested regularly. Use pull if content has long-tail distribution where most files are rarely accessed.

dimension: Origin Capacity option_a: Push CDN: Eliminates origin load entirely after deployment. Origin only handles the initial upload, not ongoing user requests. Ideal when origin capacity is constrained or expensive. option_b: Pull CDN: Origin must handle cache misses and revalidation requests. Requires origin capacity proportional to cache miss rate and content update frequency. decision_framework: Use push if origin infrastructure is expensive, limited, or unreliable. Use pull if origin has excess capacity and you want to avoid CDN storage costs.

Common Pitfalls

pitfall: Pushing Frequently-Changing Content why_it_happens: Teams treat push CDNs like pull CDNs, uploading every content change immediately. This creates constant replication jobs, delays in content availability, and operational complexity managing propagation status. how_to_avoid: Batch updates into scheduled deployments (e.g., hourly or daily releases). Use pull CDNs for content that changes more than once per hour. Reserve push CDNs for assets with predictable release cycles like application builds or marketing campaigns.

pitfall: Ignoring Propagation Delays why_it_happens: Developers assume pushed content is instantly available globally, but replication to 200+ edges can take 15-60 minutes. Deploying application code that references new CDN assets before propagation completes causes 404 errors. how_to_avoid: Implement deployment pipelines that wait for replication confirmation before updating application references. Use versioned URLs (logo-v2.png) so old and new content coexist during transitions. Monitor propagation status via CDN provider APIs.

pitfall: Over-Provisioning Edge Storage why_it_happens: Teams push all content to all edges “just in case,” paying for global storage of assets that only serve specific regions (e.g., Japanese-language content stored in South American edges). how_to_avoid: Use selective replication to match content geography with user geography. Analyze access logs to identify which edges actually serve which content. Start with regional replication and expand only when traffic patterns justify it.

Real-World Examples

company: Netflix system: Open Connect CDN usage_detail: Netflix uses push-based distribution for their massive video catalog. During off-peak hours (2-8 AM local time), they push new movie and TV show files to Open Connect Appliances (OCAs) installed in ISP networks worldwide. Each OCA stores 100-200TB of content. This push model means Netflix’s origin servers never serve video to end users—100% of streaming traffic comes from pre-positioned edge storage. The trade-off works because Netflix content has predictable demand (new releases are known in advance) and extremely high request volumes (each movie is watched thousands of times), making the storage cost negligible per stream. They accept the operational complexity of managing nightly push jobs across thousands of OCAs in exchange for eliminating origin bandwidth costs and ensuring content availability even if origin connectivity fails.

company: Fastly system: Compute@Edge with Persistent Storage usage_detail: Fastly offers push CDN capabilities through their persistent storage API, primarily used by customers with static documentation sites and marketing content. Customers upload content via API during CI/CD pipelines, and Fastly replicates it to their global edge network. A typical customer might push 10GB of documentation weekly, paying ~$0.10/GB/month for storage across 50+ edge locations ($50/month fixed cost). This same content might serve 10 million requests/month. With a pull CDN charging $0.08/GB for bandwidth, they’d pay $800/month (assuming 1KB average response size). The push model saves $750/month because storage costs are fixed while bandwidth costs scale with traffic. Fastly’s customers use push for content that changes on release cycles (weekly documentation updates, monthly marketing campaigns) but not for user-generated content or frequently-updated APIs.

Interview Expectations

Mid-Level

Mid-level candidates should explain the basic push CDN workflow: you upload content, it replicates to edges, users request from edges. They should identify the core trade-off (storage costs vs origin load) and recognize that push CDNs work best for infrequent updates. Expect them to compare push vs pull at a high level: push is proactive, pull is reactive. They should understand that push CDNs require URL rewriting to point to CDN domains. A solid answer mentions that push eliminates origin traffic after deployment and requires managing content versions explicitly.

Senior

Senior candidates must articulate the economic model: push CDNs charge for storage across all edges (GB-months), making them cost-effective only when content has high request volumes to amortize the fixed storage cost. They should discuss propagation delays and how to handle them in deployment pipelines (versioned URLs, replication confirmation). Expect analysis of when push beats pull: predictable content updates, constrained origin capacity, need for guaranteed edge presence. They should identify operational complexity: managing global deployments, monitoring replication status, handling rollbacks. Strong answers include selective replication strategies to optimize costs and discussion of how push CDNs eliminate cache miss storms that plague pull CDNs during traffic spikes.

Staff+

Staff+ candidates should design hybrid architectures: push for static assets (JS/CSS bundles, images), pull for dynamic content (API responses, personalized data). They should calculate break-even points: at what request volume does push storage cost become cheaper than pull bandwidth cost? Expect discussion of advanced topics like percentage-based rollouts across edge tiers, blue-green deployments at the edge, and handling content that’s too large to replicate globally (selective regional push). They should identify organizational implications: push CDNs require mature CI/CD pipelines and deployment automation, while pull CDNs work with simpler origin-centric workflows. Strong answers include real-world examples of companies using push (Netflix, large SaaS documentation sites) and explain why those use cases justify the operational complexity.

Common Interview Questions

When would you choose a push CDN over a pull CDN?

How do you handle content updates in a push CDN without causing downtime?

What are the cost implications of pushing 100GB of content to 200 edge locations?

How would you design a deployment pipeline for push CDN content?

What happens if content replication fails to some edge locations?

Red Flags to Avoid

Claiming push CDNs are always better or always worse than pull CDNs without considering workload characteristics

Not understanding that push CDNs charge for storage, not bandwidth

Ignoring propagation delays and assuming pushed content is instantly available globally

Recommending push CDNs for frequently-changing content (multiple updates per hour)

Not recognizing that push CDNs eliminate origin server load entirely after deployment

Key Takeaways

Push CDNs proactively replicate content to all edge locations before user requests, trading storage costs for zero origin load and guaranteed edge presence. You control deployment timing explicitly.

Push CDNs are cost-effective when content has infrequent updates (less than daily) and high request volumes that amortize fixed storage costs across many requests. Low-traffic content makes push economically inefficient.

Propagation delays (15-60 minutes to replicate globally) require deployment pipelines that wait for replication confirmation and use versioned URLs to avoid 404 errors during transitions.

The primary trade-off is operational complexity (managing global deployments, monitoring replication) versus simplicity (pull CDNs automatically propagate origin changes). Choose based on your team’s deployment maturity.

Push CDNs eliminate cache miss storms and origin capacity planning for static assets, making them ideal for predictable workloads like application releases, documentation sites, and marketing campaigns where content changes on known schedules.

Prerequisites

CDN Overview - Understand general CDN architecture and edge locations before diving into push-specific mechanics

DNS Fundamentals - DNS routing directs users to CDN edges; grasp this before understanding content distribution models

Next Steps

Pull CDNs - Compare on-demand distribution approach and understand when pull beats push

Cache Invalidation Strategies - Learn how to update content at edges after initial push deployment

Object Storage - Push CDNs often use object storage as the upload target and replication source

Blue-Green Deployments - Apply zero-downtime deployment patterns to push CDN content updates