What is the difference between a push CDN and a pull CDN?
CDNs (Content Delivery Networks) reduce latency by caching content at edge nodes geographically close to users. Push and pull CDNs differ in *who* initiates the content placement at the edge.
In a **pull CDN**, the edge node fetches content from the origin server on the first request — a **cache miss**. The CDN then stores the response and serves subsequent requests from cache until the TTL expires (driven by `Cache-Control: max-age`). The operational model is minimal: you set TTLs in your origin responses and let the CDN handle placement. The downside is the **cold start problem**: the first request to each edge node after a deploy or TTL expiry hits the origin, adding latency. Under high traffic, many simultaneous misses can cause a **thundering herd** stampede to the origin. Pull CDNs are the default for most web assets because they are self-managing — Cloudflare, Fastly, and CloudFront all operate as pull CDNs by default.
In a **push CDN**, you explicitly upload content to the CDN's storage (via API or rsync) before any user requests it. The CDN distributes your uploaded content to all edge nodes. All requests are served from edge storage — there is no origin fetch. This is appropriate for large static assets that change infrequently and must be served with zero-miss latency globally: software downloads, large media files, game patches. AWS CloudFront with S3 as origin approximates a push CDN; pure push CDNs include MaxCDN's push zones and Rackspace CDN.
The trade-offs: push CDNs require you to manage the content lifecycle — you must purge or re-upload on change, and you pay for storage at all edge nodes whether or not the content is ever requested in that region. Pull CDNs are lazily populated but require a working origin and may serve stale content until TTL expires or explicit purge is triggered.
For a typical SaaS application: use a pull CDN for dynamic API responses (short TTL or `Cache-Control: private`) and HTML, and use a pull CDN with long TTL + content-hashed filenames for static assets (JS, CSS, images). Reserve push CDN semantics for large media delivery where zero-miss SLAs are required and content lifecycle is fully controlled by your deployment pipeline.
| Aspect | Pull CDN | Push CDN |
|---|---|---|
| Content placement | Edge fetches from origin on first miss | You upload content to CDN proactively |
| Origin dependency | Yes (required for cache misses) | No (after push, origin not needed) |
| Cold start / first-request latency | Higher (origin fetch on miss) | Zero (already at edge) |
| Storage cost | Only caches what users request | All content at all edge nodes |
| Content update model | TTL expiry or explicit purge | Re-upload or purge via API |
| Best for | Dynamic sites, typical web assets | Large static files, software downloads |
| Operational complexity | Low (self-managing) | Higher (must manage push lifecycle) |
Correctly identifies the fundamental difference (lazy pull vs. proactive push) and states when each is appropriate. May not discuss thundering herd, cold start, or storage cost implications.
Explains the thundering herd problem on cache misses, discusses TTL and explicit purge for pull CDNs, describes the storage trade-off for push CDNs, names real CDN services, and can recommend a combined strategy for a typical production deployment.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment