CDN Caching Strategies: Pull, Push, and Hybrid
Two Philosophies of Cache Population
Every CDN must decide: do you cache content reactively when someone requests it (pull), or proactively before anyone asks (push)? The answer affects cold-start latency, origin load, storage efficiency, and operational complexity.
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
Pull Caching (Origin Pull)
In pull caching, the CDN fetches content from the origin server on demand — when the first user requests it.
How It Works
- User requests
/image.jpgfrom the CDN edge - Edge cache has no copy → cache miss
- Edge fetches from origin (possibly through a shield layer)
- Origin responds, edge caches the response and serves the user
- Subsequent requests for the same content are served from cache
Advantages
- No upfront storage allocation needed — only requested content is cached
- Automatic — no workflow changes required to publish content
- Storage-efficient — popular content naturally stays in cache via LRU
Disadvantages
- First request always hits origin (cold cache penalty)
- Potential cache stampede when many PoPs simultaneously miss on the same content
- Origin must be available for the CDN to function
Push Caching
In push caching, content is uploaded directly to the CDN's edge storage before users request it.
How It Works
- Content creator uploads files to CDN's storage API
- CDN distributes files to edge PoPs according to a distribution policy
- When users request content, it's already cached — every request is a hit
Advantages
- No cold-cache penalty — first request is served from cache
- Origin is not needed for serving (CDN storage is the source of truth)
- Guaranteed content availability on all edges
Disadvantages
- Storage costs — you pay for storing content on every PoP, even where nobody requests it
- Upload workflow — content must be explicitly pushed, adding operational complexity
- Propagation delay — pushing to 300+ PoPs takes time
Hybrid Strategies
Most production CDN deployments use a hybrid approach:
| Content Type | Strategy | Reasoning |
|---|---|---|
| Static assets (JS, CSS, images) | Pull + long TTL + cache warming | Assets are pulled on first request, cached for months. Warming pre-populates before launches. |
| Video/media | Push to regional PoPs | Large files benefit from pre-positioning. Users expect instant playback. |
| Dynamic content | Pull + short TTL | Content changes frequently, pull ensures freshness. See dynamic content caching. |
| Software updates | Push + global distribution | Large files, predictable release schedule, all users need it. |
Pull CDN Implementation
To use a pull CDN, you configure the CDN with your origin server address. The CDN transparently fetches and caches content:
# CDN Configuration
Origin: https://origin.example.com
Cache Rules:
*.js, *.css → Cache 1 year (content-hashed filenames)
*.html → Cache 5 minutes, stale-while-revalidate 1 hour
/api/* → Cache 60 secondsPush CDN Implementation
Push CDNs provide storage APIs (typically S3-compatible) or CLI tools for uploading content:
# Upload to CDN storage
aws s3 sync ./dist s3://cdn-bucket/ --cache-control "max-age=31536000"
# Or via CDN's API
curl -X PUT https://storage.cdn.example.com/image.jpg -H "Authorization: Bearer $TOKEN" --data-binary @image.jpgChoosing Your Strategy
Pull for most web content. Push for large media files and software distribution. Cache warming (hybrid) for time-sensitive launches where cold-cache penalties are unacceptable. Your CDN's cache hit ratio tells you if your strategy is working.