Push vs. Pull CDN
Why this matters: this is the most commonly asked CDN question in interviews, and the strong answer is neither "push" nor "pull" — it is knowing which content type each suits and saying so.
Key takeaway
CDNs use two primary models to get content from origin servers. In Push CDN, the origin automatically sends content to proxies. In Pull CDN, the CDN fetches on demand when a user first requests it.
Push CDN
The origin server automatically sends content to the proxy servers. The content provider is responsible for managing this delivery.
- Best for: static content, where the origin server decides exactly what to deliver.
- Drawback: inefficient for rapidly changing content, often resulting in redundant pushes — you ship a new version to every edge whether or not anyone requests it.
Pull CDN
The CDN fetches data from the origin only when a user requests it. Proxy servers then cache the file for a specified time-to-live to balance capacity and cost.
This model is ideal for dynamic content or high-traffic sites where pre-loading all assets is inefficient.
The comparison
| Push CDN | Pull CDN | |
|---|---|---|
| Who initiates | Origin server | First user request |
| Who manages delivery | The content provider | The CDN |
| Replicas maintained | More — improving availability for static content | Fewer — only what's been requested |
| Storage consumption | Higher | Lower |
| First request latency | Fast — already there | Slow — a cache miss reaches origin |
| Frequently changing content | Poor — redundant pushes | Good |
| Best for | Static assets, predictable catalogues | Dynamic content, high traffic, large catalogues |
In short: Push CDN maintains more replicas, improving availability for static content. Pull CDN is favored for frequently changing content and high traffic loads due to lower storage consumption.
Worked example: a website with two content types
A common interview framing. You manage a site with:
- News feed — frequently updated articles and blog posts with varying popularity.
- Static assets — the company logo, design elements, product images. These change infrequently.
| Content type | Choice | Justification |
|---|---|---|
| Static assets | Push | Small, stable, known in advance, and needed by essentially every page load. Pushing guarantees the first visitor in every region gets a cache hit, and the redundant-push drawback doesn't apply because they rarely change. |
| News feed | Pull | Frequently updated and unevenly popular. Pushing every article to every PoP would waste storage on posts nobody reads, and each edit would trigger another redundant push. Pull fetches only what's actually requested, with a short TTL so updates propagate. |
Key takeaway
Push when you know what will be wanted and it rarely changes. Pull when you don't, or it does. Real systems split by content type — and the hybrid is the correct answer, not a hedge.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Defines both: "push sends content ahead of time, pull fetches on first request." |
| L5 | Chooses per content type: "push the static assets since they're stable and universally needed, pull the articles since most are rarely read." |
| Staff+ | Names the deciding property and the failure mode: "the question is whether demand is predictable. And pure pull has a cold-start problem — the first user in every region eats an origin round trip at launch, so I'd warm the cache for known events and use tiered caching so a miss hits a regional parent, not origin." |
Next: content that can't simply be cached.