CDN Architecture Diagram: Edge PoPs, Origin Shield & Cache Invalidation

A content delivery network (CDN) puts cacheable bytes — images, scripts, APIs, video segments — closer to users so origin servers stay out of the hot path. In system design interviews and production architecture reviews, the CDN is not “just static hosting.” It is the edge tier that shapes latency, origin cost, TLS termination, and how quickly content updates propagate worldwide.

This guide covers the pieces you should draw on a CDN architecture diagram: edge points of presence (PoPs), Anycast versus DNS geo-routing, the origin shield mid-tier, cache invalidation with TTLs and surrogate keys, TLS at the edge, and the failure modes that show up in real incidents. Pair it with a clear load balancer architecture diagram when dynamic API traffic still needs an origin LB behind the CDN.

What a CDN is in the architecture

At a high level, a CDN is a globally distributed set of cache servers that answer HTTP(S) requests on behalf of your origin. Each geographic site is a point of presence (PoP). When a user requests an object:

1. Routing sends the request to a nearby PoP (Anycast or GeoDNS).
2. On a cache hit, the edge returns the object immediately — often in single-digit to low tens of milliseconds.
3. On a cache miss, the edge fetches from upstream (preferably an origin shield, then the origin), stores the response according to cache headers, and returns it to the client.

That pattern appears in almost every modern web stack, including the edge tier of eCommerce architecture diagrams, where product images and storefront assets sit left of application services.

Edge PoPs and routing: Anycast vs DNS geo

How traffic finds a PoP matters as much as what the PoP caches.

• Anycast — many PoPs advertise the same IP prefix via BGP. Routers deliver packets to the topologically nearest announcement. Failover is automatic when a PoP withdraws its route. Cloudflare and Fastly rely heavily on this model.
• GeoDNS / GSLB — the CDN DNS answers with different IPs based on the resolver’s location (or EDNS client subnet). Useful for compliance steering and fine-grained geo policy, but dependent on DNS TTLs for failover speed.

On your diagram, show Clients → Anycast/DNS → Edge PoP. Annotate “nearest PoP” so reviewers do not assume a single regional VIP. In 2026, Anycast is the default story for new global edges; call out GeoDNS only when your design needs explicit geo or regulatory routing.

Cache hierarchy and origin shield

A flat edge cache works until a popular miss storms the origin. Production CDNs add a mid-tier:

Tier	Role	What to show
L1 Edge PoP	Closest to users; highest request volume	HIT returns here; MISS arrows leave the box
L2 Origin shield	Aggregates misses; collapses duplicate fetches	One shield (or small regional set) between edges and origin
Origin	Authoritative app or object store	Sees far fewer requests with a well-tuned shield

Origin shield (CloudFront Origin Shield, Cloudflare Tiered Cache, Fastly shielding) means edges fetch from the shield first. The shield holds a single in-flight miss per object and answers sibling edges from its own cache. Without it, hundreds of PoPs can independently miss and hammer origin — a classic stampede.

Diagram rule: draw HIT as a short green return from the edge; draw MISS as Edge → Shield → Origin. One arrow per hop keeps the story readable in interviews.

Cache invalidation and surrogate keys

Caching only helps if you can refresh content on purpose. Three complementary strategies:

• TTL / Cache-Control — max-age / s-maxage expire objects passively. Simple, but mutable content stays stale until the clock runs out. Pair with stale-while-revalidate so edges can serve stale while refreshing in the background.
• URL purge — an API call removes specific URLs across PoPs (seconds of global propagation on major providers).
• Surrogate keys / cache tags — the origin attaches labels via headers such as Surrogate-Key: product-42 category-shoes. One purge-by-tag invalidates every object sharing that key, which is how teams keep long TTLs without waiting for expiry when a product or article changes.

On the diagram, place a control-plane strip under the data path: TTL expire, surrogate-key purge API, fan-out to all PoPs and the shield. That strip is what interviewers look for when they ask “how do you update a viral homepage asset?”

TLS at the edge

Most CDNs terminate HTTPS at the PoP. Clients validate the public certificate there; the CDN may re-encrypt to origin (or use a private link). Mark TLS termination on the edge box so security reviewers know where certificates and HSTS live. WAF and rate limits often sit at the same edge hop — mention them if your design includes abuse protection before traffic reaches the origin load balancer.

Failure modes teams should document

• Cache stampede — many edges miss the same key at once; mitigate with origin shield and request collapsing.
• PoP failure — Anycast withdraws the bad site; GeoDNS needs short TTLs or health-aware DNS to move users quickly.
• Stale content — long TTL without event-driven purge after publishes; fix with surrogate keys or versioned URLs (/app.abc123.js).
• Broken Vary — Vary: Cookie or User-Agent fragments the cache and destroys hit ratio; keep Vary narrow (e.g. encoding).
• Origin outage — serve stale-if-error from shield/edge when policy allows, and document the degradation path.

Practical use cases

• System design interviews — sketch Clients → CDN → Origin LB → app in under five minutes; call out shield and purge.
• eCommerce launches — cache product media at the edge; purge by product ID when prices or images change.
• Incident response — show which PoP region saw elevated origin egress during a miss storm.
• Cost reviews — quantify how shield + long TTL reduces origin bandwidth versus edge-only caching.

Example prompt for AI diagram generation

In ByteDiagram, describe the full edge path so the first draft includes shield and invalidation:

Global users → Anycast DNS → Edge PoP (L1 cache hit/miss)
→ Origin Shield (L2, request collapse) → Origin app + S3
→ Control plane: Surrogate-Key purge + TTL labels
Left-to-right layout, blue edge boxes, amber origin.

FAQ

Do I still need a load balancer if I use a CDN?

Yes for dynamic traffic. The CDN absorbs cacheable requests; uncached API calls still land on your origin VIP or LB. Diagram both: CDN left for assets, LB in front of app servers for APIs.

When is origin shield worth the extra hop?

Enable it when origin CPU, egress, or connection limits matter — viral media, large object catalogs, or sparse regional traffic that would otherwise miss independently. The added single-digit milliseconds usually beat a thundering herd.

Should I prefer versioned URLs or surrogate-key purge?

Use versioned URLs for immutable build artifacts (JS/CSS hashes). Use surrogate keys for mutable HTML and API responses that must stay at stable URLs. Many teams use both.

Conclusion

CDN architecture is about placing cache close to users, protecting origin with a shield tier, and invalidating deliberately with TTLs and surrogate keys. A precise diagram shows Clients → Anycast/DNS → Edge PoP (hit/miss) → Origin Shield → Origin, plus a control plane for purge. Start there in interviews and production docs, then annotate TLS, WAF, and the failure modes that matter for your workload.