CDN offload as a capacity lever

At scale the CDN is capacity: what melts is the origin's share, counted in requests and in bytes.

Before you read: predict

In one minute a chat app's CDN answers 100,000 requests. 95,000 are for sticker images of 20 KB that every PoP already holds; the other 5,000 are voice-note downloads of 4 MB, each a new file that no PoP holds yet. The CDN dashboard shows a 95% hit ratio.

To the nearest whole percent, what share of the bytes users received came from the origin (1 MB = 1,000 KB)?

The 30-second version

Offload is what the edge answers without the origin, counted by requests and by bytes; they differ when hits and misses differ in size. The origin carries only the misses, so plan it from them. One upper tier and request collapsing turn many PoPs' misses into few origin fetches. Serve stale on errors; give shared files versioned names.

At scale the CDN is capacity: what melts is the origin's share, counted in requests and in bytes.

How it works

Step 1 of 12

Request offload is the share of requests the edge answers from stored copies: the hit ratio on the dashboard.

In the kitchen

ninety-five sales in a hundred are candles and cushions off the store shelf, yet nearly every lorry from the factory carries wardrobes → a high hit ratio with low byte offload (steps 1–3)

Analogy: A flat-pack furniture chain

The factory makes everything; each store sells from its own stockroom; a regional warehouse restocks the stores.

In the furniture chain	In a CDN
ninety-five sales in a hundred are candles and cushions off the store shelf, yet nearly every lorry from the factory carries wardrobes	a high hit ratio with low byte offload (steps 1–3)
the factory plans its loading bays from the orders that reach it, not from how many shoppers leave happy	plan the origin from the miss side (steps 4–5)
thirty stores each order the new sofa: thirty lorries	each PoP fetches its own copy (step 6)
stores order from the regional warehouse, and only the warehouse orders from the factory	an origin shield (step 7)
a clerk who already has the sofa on order tells the next customers "it is coming" instead of ordering again	request collapsing (step 8)
during a factory strike, stores keep selling the floor stock they hold	`stale-if-error` (step 9)
a redesigned chair gets a new article number, so stores order it as a new product	a versioned URL (step 10)
recalling a chair from every store on the first day of the sale	a purge at peak (step 11)

Breaks down when: a store sells its last sofa and must wait; a cached copy can be served any number of times.

Contrasting case: a made-to-order workshop with no stockroom: every order reaches the bench, so its capacity is its whole demand (an origin with no CDN, step 4 with a 0% hit ratio).

In real terms: count what reaches the origin, in requests and in bytes, and reduce how many caches can ask it and how often.

Examples, run for real

4.1 ExamHall EXH-4270: the paper behind a cache-buster

At 09:00 the ECON-201 paper (300 KB) was requested by 2,400 candidates over five minutes through 40 PoPs. The client added ?t= and the time to every request, so every request was a new key.

4.1 before: ?t= on every request · 2400 candidates on 40 PoPs · origin fetches 2400 · origin egress 720 MB
4.1 MR: /papers/ECON-201.v7.json, max-age one year · origin fetches 40 (one per PoP) · origin egress 12 MB

MR !4570 serves the paper at a name that changes with its content, cached for a year: one fetch per PoP instead of one per candidate (steps 6, 10).

4.2 Request hit ratio against byte offload

One minute of ExamHall's CDN: question images every PoP holds, and exam recordings, each downloaded once.

4.2 one minute: 49000 image requests (30 KB, held) + 1000 recording downloads (25 MB, new) · request hit ratio 98% · bytes from the origin 94% (25000 of 26470 MB)

The dashboard's 98% describes requests; the origin still sent almost all the bytes (steps 1–4).

4.3 Ten minutes without the origin

4.3 origin down 10 min · timetable (stored, max-age=60, stale-if-error=3600): 6000 of 6000 served from stored copies (590 still fresh, 5410 stale)

The timetable rode out the outage on its stored copies, fresh for the first minute and stale after it (step 9).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 6

A ticketing site's CDN answers 60,000 requests a second with a 99% request hit ratio. A release adds a click-tracking parameter to some links, and the hit ratio falls to 98%; the traffic is unchanged.

About how many requests a second now reach the origin?

Question 2 of 6

At 12:00:00 a chat app publishes a new sticker pack. Its CDN has 200 PoPs, all behind one origin shield, and no PoP or the shield holds /stickers/pack-88.png yet. Each PoP receives 100 requests for it within the first 50 ms, and one fetch from the origin takes 200 ms.

How many requests for it reach the origin?

Question 3 of 6

A ticketing site's seat-map script /js/seatmap.js is cached for a year at each of 120 PoPs; there is no origin shield. Every event page names the script, and each PoP caches the page for 60 s. During an on-sale each PoP gets 10 page views a second, each loading the script. The origin answers a fetch in 300 ms and answers 503 at once to any fetch beyond 40 in flight. Today every deploy purges /js/seatmap.js from all PoPs, and fans get 503s for the script right after it. The team wants deploys during on-sales with no 503 and at most one origin fetch of the script per PoP per deploy.

Which change meets both?

Question 4 of 6

A video app's CDN has 20 PoPs and no origin shield. Each hour, every PoP gets a request every 30 s for each of 200 thumbnails (10 KB, max-age=300), and each of 1,000 trailers (40 MB, cached for a day) is downloaded once in each of 5 different PoPs. No two PoPs ask for the same file in the same second. The dashboard shows an 89% hit ratio, and the origin's egress bill is high.

The interviewer asks: which one change cuts the origin's egress the most?

Question 5 of 6

A payments app's origin is down for 10 minutes. In that time its CDN (10 PoPs) gets 48,500 requests for statement pages (8 KB) that every PoP stored just before, sent with max-age=60, stale-if-error=86400, and 1,500 requests for PDF statements (2 MB), each a file no PoP has stored.

Measured in bytes and to the nearest whole percent (1 MB = 1,000 KB), what share of what users asked for could the CDN not deliver?

Question 6 of 6

At 18:00:00 a chat app opens a live poll. Its results image, /poll/live-7.png, is 2 MB, changes every minute and is sent with max-age=60. Its CDN has 150 PoPs and no origin shield, and no PoP holds the image yet. For the next 10 minutes each PoP receives 10 requests a second for it, at the same moments in every PoP, and one fetch from the origin takes 250 ms.

How many megabytes does the origin send for it in those 10 minutes?

Go deeper

Pro tips

Put byte offload and origin egress on the CDN dashboard beside the request hit ratio, and alert on origin egress. When: a CDN fronts files of very different sizes, or the origin's bandwidth bill is a concern (steps 1–5). Verify:
```
tip same minute as 4.2 · request hit ratio 98% · byte offload 6%
```
Status: RAN.

Source

quote-check.mjs finds every passage below verbatim in its saved text. Valid as of 2026-10-15.

RFC 5861, HTTP Cache-Control Extensions for Stale Content: https://www.rfc-editor.org/rfc/rfc5861.txt (rfc5861.txt).
Cloudflare docs, Tiered Cache: https://developers.cloudflare.com/cache/how-to/tiered-cache/ (cf-tiered-cache.txt). The row's second source. Quoted: "If the upper-tier does not have the content, only the upper-tier can ask the origin for content. This practice improves bandwidth efficiency by limiting the number of data centers that can ask the origin for content, which reduces origin load and makes websites more cost-effective to operate."
Amazon CloudFront Developer Guide, Use Amazon CloudFront Origin Shield: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html (cloudfront-origin-shield.txt). The row's third source. Quoted: "Requests for content that is not in Origin Shield’s cache are consolidated with other requests for the same object, resulting in as few as one request going to your origin." and "When viewers are in different geographical regions, requests can be routed through different regional edge caches, each of which can send a request to your origin for the same content."
Amazon CloudFront Developer Guide, Request and response behavior for custom origins (same guide as the row's third source): https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html (cloudfront-request-collapsing.txt). Quoted from "Simultaneous requests for the same object (request collapsing)": "if additional requests for the same object (with the same cache key) arrive at the edge location before CloudFront receives the response to the first request—CloudFront pauses before forwarding the additional requests to the origin." and "CloudFront sends the response from the original request to all the requests that it received while it was paused."

Steps 1–5 and 11 are the counting lib/cdn.mjs does, not quoted rules; step 10 is the row's pro tip, executed in P3.

Checked against the tools and docs as of 2026-10-15.

Predict first