# Content Delivery

> This skill should be used when the user asks about a "CDN", "edge caching", "static asset delivery", "media / video delivery", "geo distribution of content" or "edge POP selection", "push vs pull CDN", "cache-control headers" / "TTL for static assets", "origin offload", or "origin shield". It gives the recipe for serving bytes from the edge close to users. Use it whenever a design serves images, video, JS/CSS, or downloads to a wide geography, or the origin is saturated by repeat reads of the same files, even if the user doesn't say "CDN".

- Skill: `proyecto26/content-delivery` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add proyecto26/content-delivery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/proyecto26/content-delivery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: proyecto26 (https://skillmd.com/u/proyecto26)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/proyecto26/content-delivery

---


# Content Delivery

Push bytes to the network edge so requests terminate close to the user and never
reach the origin. A CDN is the outermost cache layer of a system: get it right and
most static/media traffic and a chunk of latency vanish before they hit your
servers; get it wrong and you serve stale assets, leak origin load, or pay egress
twice.

## When to reach for this
The same files (images, video, JS/CSS bundles, downloads, fonts) are read
repeatedly by a geographically spread audience; the origin or its bandwidth is the
bottleneck for static reads; or cross-region latency on first byte hurts (a
cross-continent round trip is ~100 ms — see `back-of-the-envelope`). A CDN buys
latency *and* origin offload at once.

## When NOT to
Highly personalized, per-request dynamic responses with no cacheable shape (a CDN
adds a hop and caches nothing). Tiny single-region audiences where the origin
already serves reads comfortably (YAGNI — a CDN is another vendor, another bill,
another invalidation problem). Strictly fresh data that cannot tolerate any
staleness window — that belongs at the origin or behind `consistency-coordination`,
not a TTL-based edge. Naming a CDN before a number shows static reads or geography
is the problem is a red flag.

## Clarify first
- **Content mix** — what fraction is cacheable static/media vs uncacheable
  dynamic/personalized? (Only the cacheable part benefits.)
- **Update cadence & staleness budget** — how often do assets change, and how
  stale may an edge copy be? (Drives TTL and invalidation strategy.)
- **Geography** — where are users, and how concentrated? (Decides whether edge PoPs
  and geo-routing matter at all.)
- **Object size & egress volume** — average asset size × requests = egress; this
  sizes the bill and the offload (→ `back-of-the-envelope`).
- **Origin shape** — object store (S3/GCS/blob) or dynamic app server? Can it
  survive a cold-cache stampede if the edge flushes?

## The options

**Distribution model — how content reaches the edge**
- **Pull (origin-pull):** the edge fetches on first miss, caches per TTL, serves
  the rest. *Use when* traffic is high and content is large or churny — the edge
  holds only what's actually requested. The default for most systems.
- **Push:** you upload assets to the CDN ahead of demand and rewrite URLs.
  *Use when* the catalog is small/static or launch spikes can't tolerate a cold
  first-miss (you pre-warm); you accept managing storage and uploads yourself.

**Caching key & TTL — what the edge keys on and for how long**
- **Long TTL + fingerprinted URLs** (`app.4f9a.js`, `image.png?v=2`): immutable
  assets cached for months; a content change is a *new URL*, not an invalidation.
  *Use when* you control asset URLs — the cleanest model.
- **Short TTL / `stale-while-revalidate`:** bound staleness for content that
  changes on a schedule. *Use when* URLs are stable but content updates.

**Edge proximity & routing — how a user reaches the nearest PoP**
- **Anycast / DNS geo-routing:** route each user to the closest healthy edge.
  *Use when* the audience is multi-region (almost always, for a CDN). Shared with
  `load-balancing` — see there for the routing mechanics.

**Origin protection — shrinking the origin's exposed surface**
- **Origin shield / mid-tier cache:** a single regional cache layer in front of the
  origin that all edges pull through, collapsing N edge misses into one origin
  fetch. *Use when* origin offload or stampede protection matters more than a
  little extra latency on cold misses.

## Trade-offs

| Option | What it solves | What it worsens | Change it when |
|---|---|---|---|
| Pull CDN | Edge holds only requested content; no upload pipeline | First request per object is a slow miss; redundant re-pulls when TTL expires before content changes | Cold-miss latency or launch spikes hurt → push / pre-warm |
| Push CDN | No cold miss; full control of what's cached and when | You own upload + storage + URL rewriting; pay to store rarely-read assets | Catalog grows or churns → pull |
| Long TTL + fingerprinted URLs | Near-permanent caching; updates are new URLs (no invalidation race) | Requires build/URL control; old versions linger at edge until aged out | URLs are not under your control → short TTL |
| Short TTL / stale-while-revalidate | Bounded staleness on stable URLs | More origin revalidation traffic; synchronized expiry can stampede | Content is truly immutable → fingerprint + long TTL |
| Geo-routing / anycast | Users hit the nearest edge; lower latency | More PoPs to reason about; routing can send users to a degraded PoP | Single-region audience → skip it |
| Origin shield | Collapses edge misses into one origin fetch; protects origin | Extra hop on cold path; the shield is a new chokepoint/SPOF if single-region | Origin is robust and offload is already enough → drop it |

## Behavior under stress
A CDN usually *absorbs* load spikes — that's its job — but it has its own failure
shapes, and they tend to dump straight onto the origin.

- **Cold cache / mass eviction:** after a purge, config push, or TTL synchronized
  expiry, edge hit rate craters and every PoP pulls from the origin at once. This
  is a `caching` thundering herd at global scale. *Mitigate:* origin shield to
  collapse misses, TTL jitter, `stale-while-revalidate` so the edge serves stale
  while it refetches, staged purges.
- **Cache busting / low hit rate:** unbounded query-string variation or cookies in
  the cache key explode the keyspace so nothing stays cached — the origin sees full
  traffic while you still pay the CDN. *Mitigate:* normalize/whitelist cache-key
  params; strip cookies on static paths.
- **Hot object:** one viral file can exceed a single PoP's capacity, but CDNs scale
  this far better than an origin — the real risk is a hot *uncacheable* path
  punching through to the origin.
- **CDN outage / partial PoP failure:** the edge is now a dependency in front of
  everything. Plan origin fallback (clients or DNS failover to origin) and accept
  the origin must briefly take full load, or use a second CDN (multi-CDN).
- **Egress surprise:** a misconfigured `no-cache` or a hot uncacheable asset can
  10× the origin egress bill silently.

**Monitor:** edge hit ratio (cache hit rate), origin offload %, origin request rate
(the number that spikes when the edge fails), p95 edge latency by region, egress
bytes, and 4xx/5xx at the edge vs origin.

## How to apply
1. **Clarify the inputs** — content mix (cacheable fraction), staleness budget,
   geography, object size × volume, and origin shape (see `Clarify first`). If the
   cacheable fraction is near zero or the audience is single-region, stop here.
2. **Pick the distribution model and cache key** from the trade-off table: default
   to **pull**; switch to **push/pre-warm** only when cold-miss latency or launch
   spikes hurt. Prefer **long TTL + fingerprinted URLs** when you control URLs,
   else **short TTL / `stale-while-revalidate`**.
3. **Set the knobs** — `Cache-Control` (max-age, immutable, stale-while-revalidate),
   the cache key (URL path + whitelisted params; strip cookies on static paths),
   `Vary` only where you truly differ, and add an **origin shield** if offload or
   stampede protection matters.
4. **Stress-test the design** — walk a global purge, a config push, and a CDN/PoP
   outage. Confirm TTL jitter + `stale-while-revalidate` + shield keep the origin
   survivable, and that a client/DNS fallback to origin exists.
5. **Size it with numbers** — estimate hit ratio (target 90%+), origin offload %,
   and egress (`requests × avg object size`) via `back-of-the-envelope`. If egress
   or origin request rate is alarming, revisit the cache key and TTL.
6. **Pick a provider** — default to the generic recipe; if a cloud is named, read
   its provider file for the service mapping and limits (see `Choosing a provider`).

## Dos and don'ts
**Do**
- Fingerprint immutable assets and cache them for months — turn updates into new
  URLs, not invalidations.
- Whitelist cache-key params and strip cookies on static paths to keep hit ratio high.
- Add `stale-while-revalidate` and TTL jitter so synchronized expiry can't stampede
  the origin.
- Add an origin shield when many edges would otherwise miss to the origin at once.
- Plan an origin/DNS fallback (or multi-CDN) for a CDN or PoP outage.
- Monitor edge hit ratio and origin request rate — the number that spikes when the
  edge fails.

**Don't**
- Reach for a CDN before a number shows static reads or geography is the bottleneck.
- Let unbounded query strings or `Vary: Cookie` explode the keyspace and gut caching.
- Treat a single-region origin shield as free — it is a new chokepoint/SPOF.
- Cache strictly-fresh data on a TTL when zero staleness is required.
- Ship a careless `no-cache` on a hot asset — it can silently 10× origin egress.

## Numbers that matter
The decisive quantities are **hit ratio** (90%+ is the goal; below ~80% question
whether content is cacheable), **origin offload %** (1 − origin-requests/total),
and **egress** (`requests × avg object size`). Edge-vs-origin latency is the
payoff: an edge hit is a same-region round trip (~ms to tens of ms) instead of a
cross-continent one (~100 ms). Do the egress and offload math with
`back-of-the-envelope` — don't restate its tables here; egress is the line item
that usually dominates a CDN bill.

## Interface sketch
The contract is mostly **HTTP cache headers** the origin sets and the edge obeys:
- `Cache-Control: public, max-age=31536000, immutable` for fingerprinted static.
- `Cache-Control: public, max-age=60, stale-while-revalidate=600` for stable URLs
  with periodic updates.
- `ETag` / `Last-Modified` to enable cheap revalidation (304 Not Modified).
- `Vary` only on headers you truly serve differently on (a careless `Vary: Cookie`
  destroys hit rate).
- The **cache key**: URL path + an explicit whitelist of query params; decide which
  cookies/headers (if any) are part of it.
Invalidation is a `PURGE`/invalidation API call *or* (preferably) a URL version
bump. Versioned URLs sidestep the purge-propagation race entirely.

## Choosing a provider
Default to the generic recipe above. If the user names a cloud, read
`references/providers/<provider>.md` for the managed-service mapping,
quotas/limits, and provider-specific trade-offs. If no file exists for that
provider, the generic recipe is the answer.

## Diagram
To visualize the edge → shield → origin pull path (and the dashed cold-miss arrow,
plus geo-routing from clients to the nearest PoP), use the in-plugin
`architecture-diagram` skill. Sketch the edge nodes in the cache color and the
origin in its store color; do not embed Mermaid here.

## Related building blocks
- `caching` — *owned-concept lives in*: invalidation, eviction, TTL, and
  thundering-herd theory live there; the CDN is the edge tier *above* the
  app/distributed cache and *alternative to* origin reads for static/media.
- `load-balancing` — *owned-concept lives in*: the geo/anycast routing and origin
  health checks that send users to the nearest edge.
- `back-of-the-envelope` — *feeds into* this: supplies the egress, offload %, and
  latency-payoff numbers that justify a CDN.
- `data-storage` — *depends on*: the object store that is usually the CDN's origin.
- `consistency-coordination` — *alternative to* this for data that cannot tolerate
  any staleness window (serve from origin, not a TTL-based edge).
- `system-design` — *pairs with* (back-link): the orchestrator that routes here when
  a design serves static/media at geographic scale.

## References
- **`references/deep-dive.md`** — cache-key normalization, `Cache-Control` directive
  semantics, push vs pull mechanics, origin shield / tiered topology, invalidation
  vs versioning races, multi-CDN, and media-specific delivery (segmented HLS/DASH,
  range requests, signed URLs). Read when designing the edge layer in detail.
- **`references/providers/{generic,aws,azure,gcp}.md`** — service mappings, limits, and pitfalls per environment.