content-delivery

Name: content-delivery
Author: proyecto26

46installs1forks

How to install content-delivery?

proyecto26/system-design-skills/content-delivery

$npx -y skills add proyecto26/system-design-skills --skill content-delivery

Installs into the current project.

Summary

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 "origi

Files · 1

View on GitHub

SKILL.md

1	# Content Delivery
2
3	Push bytes to the network edge so requests terminate close to the user and never
4	reach the origin. A CDN is the outermost cache layer of a system: get it right and
5	most static/media traffic and a chunk of latency vanish before they hit your
6	servers; get it wrong and you serve stale assets, leak origin load, or pay egress
7	twice.
8
9	## When to reach for this
10	The same files (images, video, JS/CSS bundles, downloads, fonts) are read
11	repeatedly by a geographically spread audience; the origin or its bandwidth is the
12	bottleneck for static reads; or cross-region latency on first byte hurts (a
13	cross-continent round trip is ~100 ms — see `back-of-the-envelope`). A CDN buys
14	latency and origin offload at once.
15
16	## When NOT to
17	Highly personalized, per-request dynamic responses with no cacheable shape (a CDN
18	adds a hop and caches nothing). Tiny single-region audiences where the origin
19	already serves reads comfortably (YAGNI — a CDN is another vendor, another bill,
20	another invalidation problem). Strictly fresh data that cannot tolerate any
21	staleness window — that belongs at the origin or behind `consistency-coordination`,
22	not a TTL-based edge. Naming a CDN before a number shows static reads or geography
23	is the problem is a red flag.
24
25	## Clarify first
26	- Content mix — what fraction is cacheable static/media vs uncacheable
27	dynamic/personalized? (Only the cacheable part benefits.)
28	- Update cadence & staleness budget — how often do assets change, and how
29	stale may an edge copy be? (Drives TTL and invalidation strategy.)
30	- Geography — where are users, and how concentrated? (Decides whether edge PoPs
31	and geo-routing matter at all.)
32	- Object size & egress volume — average asset size × requests = egress; this
33	sizes the bill and the offload (→ `back-of-the-envelope`).
34	- Origin shape — object store (S3/GCS/blob) or dynamic app server? Can it
35	survive a cold-cache stampede if the edge flushes?
36
37	## The options
38
39	Distribution model — how content reaches the edge
40	- Pull (origin-pull): the edge fetches on first miss, caches per TTL, serves
41	the rest. Use when traffic is high and content is large or churny — the edge
42	holds only what's actually requested. The default for most systems.
43	- Push: you upload assets to the CDN ahead of demand and rewrite URLs.
44	Use when the catalog is small/static or launch spikes can't tolerate a cold
45	first-miss (you pre-warm); you accept managing storage and uploads yourself.
46
47	Caching key & TTL — what the edge keys on and for how long
48	- Long TTL + fingerprinted URLs (`app.4f9a.js`, `image.png?v=2`): immutable
49	assets cached for months; a content change is a new URL, not an invalidation.
50	Use when you control asset URLs — the cleanest model.
51	- Short TTL / `stale-while-revalidate`: bound staleness for content that
52	changes on a schedule. Use when URLs are stable but content updates.
53
54	Edge proximity & routing — how a user reaches the nearest PoP
55	- Anycast / DNS geo-routing: route each user to the closest healthy edge.
56	Use when the audience is multi-region (almost always, for a CDN). Shared with
57	`load-balancing` — see there for the routing mechanics.
58
59	Origin protection — shrinking the origin's exposed surface
60	- Origin shield / mid-tier cache: a single regional cache layer in front of the
61	origin that all edges pull through, collapsing N edge misses into one origin
62	fetch. Use when origin offload or stampede protection matters more than a
63	little extra latency on cold misses.
64
65	## Trade-offs
66
67	\| Option \| What it solves \| What it worsens \| Change it when \|
68	\|---\|---\|---\|---\|
69	\| 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 \|
70	\| 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 \|
71	\| 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 \|
72	\| Short TTL / stale-while-revalidate \| Bounded staleness on stable URLs \| More origin revalidation traffic; synchronized expiry can

People who liked this also viewed

6 picks

Type

content-delivery

46installs1forks

View on GitHub

How to install content-delivery?

proyecto26/system-design-skills/content-delivery

$npx -y skills add proyecto26/system-design-skills --skill content-delivery

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Content Delivery
2
3	Push bytes to the network edge so requests terminate close to the user and never
4	reach the origin. A CDN is the outermost cache layer of a system: get it right and
5	most static/media traffic and a chunk of latency vanish before they hit your
6	servers; get it wrong and you serve stale assets, leak origin load, or pay egress
7	twice.
8
9	## When to reach for this
10	The same files (images, video, JS/CSS bundles, downloads, fonts) are read
11	repeatedly by a geographically spread audience; the origin or its bandwidth is the
12	bottleneck for static reads; or cross-region latency on first byte hurts (a
13	cross-continent round trip is ~100 ms — see `back-of-the-envelope`). A CDN buys
14	latency and origin offload at once.
15
16	## When NOT to
17	Highly personalized, per-request dynamic responses with no cacheable shape (a CDN
18	adds a hop and caches nothing). Tiny single-region audiences where the origin
19	already serves reads comfortably (YAGNI — a CDN is another vendor, another bill,
20	another invalidation problem). Strictly fresh data that cannot tolerate any
21	staleness window — that belongs at the origin or behind `consistency-coordination`,
22	not a TTL-based edge. Naming a CDN before a number shows static reads or geography
23	is the problem is a red flag.
24
25	## Clarify first
26	- Content mix — what fraction is cacheable static/media vs uncacheable
27	dynamic/personalized? (Only the cacheable part benefits.)
28	- Update cadence & staleness budget — how often do assets change, and how
29	stale may an edge copy be? (Drives TTL and invalidation strategy.)
30	- Geography — where are users, and how concentrated? (Decides whether edge PoPs
31	and geo-routing matter at all.)
32	- Object size & egress volume — average asset size × requests = egress; this
33	sizes the bill and the offload (→ `back-of-the-envelope`).
34	- Origin shape — object store (S3/GCS/blob) or dynamic app server? Can it
35	survive a cold-cache stampede if the edge flushes?
36
37	## The options
38
39	Distribution model — how content reaches the edge
40	- Pull (origin-pull): the edge fetches on first miss, caches per TTL, serves
41	the rest. Use when traffic is high and content is large or churny — the edge
42	holds only what's actually requested. The default for most systems.
43	- Push: you upload assets to the CDN ahead of demand and rewrite URLs.
44	Use when the catalog is small/static or launch spikes can't tolerate a cold
45	first-miss (you pre-warm); you accept managing storage and uploads yourself.
46
47	Caching key & TTL — what the edge keys on and for how long
48	- Long TTL + fingerprinted URLs (`app.4f9a.js`, `image.png?v=2`): immutable
49	assets cached for months; a content change is a new URL, not an invalidation.
50	Use when you control asset URLs — the cleanest model.
51	- Short TTL / `stale-while-revalidate`: bound staleness for content that
52	changes on a schedule. Use when URLs are stable but content updates.
53
54	Edge proximity & routing — how a user reaches the nearest PoP
55	- Anycast / DNS geo-routing: route each user to the closest healthy edge.
56	Use when the audience is multi-region (almost always, for a CDN). Shared with
57	`load-balancing` — see there for the routing mechanics.
58
59	Origin protection — shrinking the origin's exposed surface
60	- Origin shield / mid-tier cache: a single regional cache layer in front of the
61	origin that all edges pull through, collapsing N edge misses into one origin
62	fetch. Use when origin offload or stampede protection matters more than a
63	little extra latency on cold misses.
64
65	## Trade-offs
66
67	\| Option \| What it solves \| What it worsens \| Change it when \|
68	\|---\|---\|---\|---\|
69	\| 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 \|
70	\| 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 \|
71	\| 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 \|
72	\| Short TTL / stale-while-revalidate \| Bounded staleness on stable URLs \| More origin revalidation traffic; synchronized expiry can

People who liked this also viewed

6 picks

Type