What this prompt does
This prompt asks the AI to design a CDN from scratch, serving [content_type] to [user_regions] at [peak_bandwidth]. It covers ten areas: edge server and PoP placement, a cache hierarchy from L1 edge through L2 regional to origin shield and origin, cache key and vary-header design, invalidation via [invalidation_method], origin pull versus push, geographic DNS routing, TLS termination at the edge, DDoS and WAF protection, real-time analytics, and cost optimization through cache hit ratios.
The structure works because a CDN is fundamentally a layered caching and routing problem, and each layer has its own keys, TTLs, and failure modes. Passing [content_type] shapes how cacheable the traffic is — static assets behave very differently from API responses. [user_regions] drives PoP placement and DNS routing, [peak_bandwidth] sizes capacity planning, and [invalidation_method] (like tag-based purge with stale-while-revalidate) determines how quickly stale content clears without hammering the origin.
When to use it
- You're learning how CDNs work end to end and want a structured mental model
- You're designing an edge/caching layer and need a cache hierarchy that offloads the origin
- You need an invalidation strategy via
[invalidation_method]that won't cause origin storms - You're planning PoP placement across
[user_regions] - You're sizing capacity and cost against
[peak_bandwidth]and hit-ratio targets - You want TLS-at-edge and DDoS/WAF integration designed in, not bolted on
Example output
Expect a layered design: edge and PoP topology for [user_regions], the L1/L2/origin-shield/origin hierarchy with cache-key and vary rules, an invalidation flow using [invalidation_method], a geographic DNS routing approach with latency fallback, a TLS and certificate-management section, and capacity planning sized to [peak_bandwidth]. It typically closes with failure-mode analysis and cost-optimization targets.
Pro tips
- Set
[content_type]precisely; cacheability of static images versus dynamic API responses changes the entire cache-key design - Use a real
[peak_bandwidth]figure so the capacity planning and PoP sizing aren't fictional - Lean on
[invalidation_method]— tag-based purge with stale-while-revalidate avoids origin storms that naive purging causes - Ask the model to detail the cache-key and vary-header rules; subtle vary mistakes cause cache fragmentation or poisoning
- Push on the origin-shield layer; it's the piece that protects your origin when edge caches miss en masse
- Have it spell out failure modes per layer — what happens when a PoP or the origin shield goes down
