CDN push vs pull

The decision

A content delivery network (CDN) is a network of cache servers in many cities. Each cache server is an edge. Your own server or object storage is the origin. In the pull way, the edge fetches a file from the origin when a user first asks. It keeps the file for its time to live (TTL). In the push way, you upload the file to the CDN before any user asks. Pull is the usual default.

Choose pull when

• You have many files and nobody knows which will be popular.
• Files change often. With pull you can rename the file or wait for the TTL.
• You want the least work. The CDN fills itself from the origin.
• Most requests go to a small set of popular files, which are cached after the first miss.

Choose push when

• You know the files in advance and a crowd will arrive at one moment, such as an app update or a film release.
• Files are huge, so a miss is slow. The origin is weak, far away, or costs money for each byte sent out.
• Rare files must always be fast. Otherwise a rare file has often expired when the next user asks.

The numbers that change the answer

Worked example at Indian scale. An app serves files from Mumbai. Assumptions: a user is 120 ms from Mumbai and 15 ms from the nearest edge. The edge is 40 ms (round trip) from the origin and keeps a connection open to it. A new connection needs 3 round trips. The edge answers in 5 ms and the origin in 20 ms. There are 50 edges.

A hit is 380 / 50 = 7.6 times faster than no CDN. A miss is still faster than no CDN.

A launch. Assumption: a new 200 KB file gets 5,000 requests per second from the first second. Until an edge stores the file, every request there is a miss and goes to the origin. A miss takes 110 ms, so 5,000 x 0.11 = 550 requests are misses. That is 550 x 200 KB = 110 MB, arriving at 5,000 x 200 KB = 1,000 MB per second = 8 Gbps. A server with a 1 Gbps link at 70% load carries 0.7 Gbps, so 8 / 0.7 = 11.4, which is 12 servers. For a small file the burst lasts about 0.11 seconds. For a huge file each miss lasts longer, so the burst does too.

With push, the origin sends the file once to each edge: 50 x 200 KB = 10,000 KB = 10 MB. Edges that join requests send only 50 requests (one with a shield), but the first users still wait for the miss.

A rarely used file. Assumption: 0.005 requests per second in the whole country. Per edge: 0.005 / 50 = 0.0001 per second. Hit rate = reads in one TTL / (reads in one TTL + 1).

• TTL of 1 hour: 0.0001 x 3,600 = 0.36. Hit rate = 0.36 / 1.36 = 26.5%.
• TTL of 1 day: 0.0001 x 86,400 = 8.64. Hit rate = 8.64 / 9.64 = 89.6%.

Push has no expiry, so the hit rate is near 100%. The price is storage. Assumption: 1,000,000 files of 200 KB are 200 GB. At all 50 edges that is 200 GB x 50 = 10,000 GB = 10 TB.

What breaks with each choice

• Pull: the first user at each edge pays the miss. After a purge or a release, all edges are empty and all ask the origin together. Fix: let each edge join requests for one file. An origin shield, an extra cache layer in front of the origin, joins them into one.
• Pull: a cookie or a changing query string in the cache key makes every user a miss. Keep them out of the key.
• Push: you must upload every version and remove old ones. If the upload job fails, users get a missing file or an old one.
• Push: you pay to store files that nobody reads.

What it costs

• Pull costs nothing to start. You pay in origin traffic on misses.
• Push costs an upload job, a clean-up job and storage. For one launch it is small: a script that sends each file once.
• To change a file under pull, give it a new name, such as app.8f3a1.js. The provider's own guide advises this for files that change often, and says it is cheaper than purging (see Sources).

How each level answers

SDE-1: Pull means the edge fetches a file when a user first asks. Push means I upload the file to the CDN first.

SDE-2: I use pull for most sites, because the CDN fills itself. I use push for a known launch, so the first users do not hit the origin together.

Senior: A hit takes 50 ms and a miss 110 ms, against 380 ms with no CDN. A cold launch can burst at 8 Gbps to the origin, so I push the file or add an origin shield. The risk is a failed upload job. The fallback is pull, which still works when a file is missing.

Staff: I ask what a slow launch costs in lost users, and who pays for origin traffic. I start with pull and add push for planned events only. I want versioned file names, so a rollback is a name change and not a purge. I check the hit rate, origin traffic during launches, and time to first byte at the 95th percentile.

Say it in the interview

I would use pull by default, with versioned file names. For a planned launch I would push the files first. A cold start at 5,000 requests per second can burst at 8 Gbps into my origin. If the push fails, pull still serves the file.

Common mistakes

• Choosing push for a large, unpredictable catalog. You pay to store files nobody asks for.
• Purging everything after each release. All edges go cold and the origin takes the crowd.
• Putting the login cookie in the cache key. The hit rate falls to almost nothing.
• Caching personal pages at the edge. One user can then see another user's page.

Sources

• Versioned names are advised over invalidation for files that change often, and are cheaper: Amazon CloudFront guide, "Invalidate files", https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html (opens in a new tab) (checked 26 Oct 2026).
• Origin Shield joins requests for one object into as few as one origin request; extra charge: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html (opens in a new tab) (checked 26 Oct 2026).
• All timings, request rates, file counts and sizes are assumptions made for teaching.