Push CDN vs Pull CDN

Both models put your bytes on edge servers close to users; they differ only in who triggers the copy and when — a pull CDN lazily fetches an object from your origin on the first cache miss and caches it under a TTL, while a push CDN treats the edge as authoritative storage that you populate ahead of time and never falls back to an origin. That single decision — lazy fetch vs. eager upload — drives every trade-off below: who bears origin load, how stale content can get, and who owns cache lifecycle.

The mechanism, request by request

Follow one object, /videos/launch.mp4 (say 200 MB), through both models. In a pull CDN the edge is a cache: on a miss it opens a connection back to origin, streams the object through to the user while writing it to local disk, and stamps it with a TTL derived from your Cache-Control: max-age header. In a push CDN the edge is origin storage: you (or your CI pipeline) uploaded the object to a storage bucket the CDN replicates, so there is no origin behind it to miss to.

Worked example: origin load and cost for a 200 MB file

Suppose launch.mp4 is 200 MB and gets 1,000,000 downloads across 50 edge PoPs in a month. Assume pull TTL = 1 hour and the file is requested at every PoP steadily, so each PoP re-fetches it once per hour. That is 50 PoPs × 720 hours = 36,000 origin fetches/month — versus push, where you upload it 50 times, once (one replication per PoP), and never again until you change it.

The pull number collapses if you raise the TTL: at TTL = 24h it drops to 50 × 30 = 1,500 fetches (~293 GB). This is the real lever — pull origin load is a function of TTL and PoP count, not of user traffic. Push origin load is a function of how often you publish, full stop.

Pitfalls

• Thundering herd on a pull miss. When a hot object's TTL expires, thousands of concurrent requests can all miss simultaneously and stampede the origin. Mitigate with request coalescing (Fastly, Cloudflare, and Nginx call it collapsed forwarding / proxy_cache_lock) so one fetch fills the cache while others wait.
• Low hit ratio on long-tail content kills the pull model. If most objects are requested once before TTL expiry, nearly every request is a miss and the CDN becomes an expensive, slow reverse proxy. Check your PoP-level hit ratio, and judge it with the one-line model rather than a magic number: blended latency = h·25 ms + (1−h)·420 ms — at h = 0.8 that is ~104 ms, and 20% of your bytes still hit origin. There is no universal cutoff: compute the h where your latency SLO or your origin-egress bill breaks, and treat ~80% as a smell threshold (an explicitly rough heuristic), not a rule.
• Push replication is not atomic. During a large re-upload, some PoPs serve the new version and some the old one. Version your paths (/v2/launch.mp4) or the CDN's staging/atomic-swap feature instead of overwriting in place, or users get a torn mix mid-deploy.
• Forgetting to purge on a pull CDN. A pushed Cache-Control: max-age=31536000 on mutable HTML means users are stuck with stale content for a year. Fingerprint immutable assets (app.9f2c.js) and keep short TTLs + explicit purges for mutable ones.
• Push storage cost creep. Because push never evicts, deleted-but-not-purged objects and abandoned versions accumulate and you keep paying storage on all of them. You must run lifecycle cleanup yourself.

When to use which — the decision rule

Choose PULL when your catalog is large and mostly dynamic or long-lived-but-cacheable (a media site, an e-commerce product catalog, API responses, a typical web app), traffic is skewed so a small hot set dominates, and you want zero-config setup with automatic cache lifecycle. The cost you accept: a slow first-request per PoP, and origin must stay up and reachable to backfill misses. This covers the vast majority of workloads, which is why Cloudflare, Fastly, and Amazon CloudFront default to pull.

Choose PUSH when objects are large, few, and infrequently requested (software installers, game patches, firmware, backup archives, big video assets), where a pull model would suffer a slow cold-miss on every object because nothing stays hot enough to keep cached — and where you'd rather pay predictable storage than unpredictable, latency-inducing origin fetches. You also gain the ability to pre-warm content before a launch spike. The cost: you own upload orchestration, versioning, and storage lifecycle. Historically this is Akamai NetStorage / Rackspace Cloud Files territory.

Prefer pull over push unless you can name a specific reason push wins, because pull's operational simplicity is worth a lot. Prefer push over a pull CDN with a huge TTL when you need a guaranteed cold-hit and can't tolerate even one slow origin fetch per PoP (e.g., a synchronized global game-patch drop). In practice most modern shops run pull and solve push's problems with cache pre-warming (issuing synthetic requests to force objects hot before a spike) — a hybrid that keeps pull's simplicity while borrowing push's readiness.

Takeaways

• Pull = lazy fetch on miss + TTL; push = eager upload to edge-as-origin. Everything else follows from that one difference.
• Pull origin load scales with TTL and PoP count, not user traffic; push origin load scales with publish frequency. Raising TTL is the cheapest way to cut pull origin egress.
• Pull wins on large dynamic catalogs and easy setup; push wins on a small set of large, rarely-requested files where a per-object cold miss is unacceptable.
• Modern default is pull + pre-warming; reach for a true push CDN only when guaranteed cold-hits or predictable storage cost genuinely matter.

Re-authored and deepened for this guide. Sources: Cloudflare and Fastly documentation on cache TTL, purging, and request collapsing; AWS CloudFront developer guide (origin fetch and cache behavior); Akamai NetStorage product docs; and standard system-design references (Alex Xu, System Design Interview; Grokking the System Design Interview). Latency and egress figures are illustrative order-of-magnitude estimates, not vendor benchmarks.