Media & streaming, an interactive architecture walkthrough
Content delivery network: how the architecture works
How a CDN routes users to a nearby PoP, serves cached copies, shields the origin with a regional tier, and purges content worldwide in seconds.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A content delivery network caches copies of a customer's files and pages in many points of presence (PoPs) around the world, so users are served from a nearby server instead of the customer's origin. Users reach the nearest PoP through anycast routing; edge servers there terminate TLS, apply security rules, and answer from a local cache of hot objects in memory and the rest on SSD.
Misses go to a regional shield cache before the origin, and concurrent requests for the same object are collapsed into one fetch, so the origin sees a small fraction of the traffic. Freshness follows the origin's Cache-Control headers, and expired objects can be revalidated in the background while the stale copy is still served. A control plane distributes configuration, certificates and purge requests to every PoP within seconds. This is a simplified learning design, not any provider's actual network.
Trade-offs and what changes at scale
Long cache lifetimes give high hit ratios but make changes slow to appear, which is why versioned URLs and fast purges are used together. A shield tier reduces origin load but adds a hop on every miss. Serving stale content keeps sites up when the origin fails, at the cost of sometimes showing outdated data. Personalised responses cannot be shared between users and must be marked private or bypass the cache. At larger scale the limits are PoP disk capacity for long-tail content and the speed of fanning out purges and config to hundreds of locations.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
A browser resolves the asset's hostname and Anycast DNS answers with an address that every PoP announces. Internet routing then delivers the connection to a nearby PoP without the DNS server needing to know where the user is.
Inside the PoP, the PoP Load Balancer spreads connections across Edge Servers, which terminate TLS with the customer's certificate. Finishing the TLS handshake a few milliseconds from the user is a large part of the speed-up on its own.
The request passes the WAF & Bot Rules before any cache lookup or origin fetch. Attack traffic is absorbed across hundreds of PoPs instead of reaching the customer's servers.
The edge server builds a cache key from host, path and only the query parameters and headers the customer configured, then checks the Edge Cache. Normalising the key matters: an ignored tracking parameter would otherwise make every URL a miss.
On a hit, Edge Servers return the object while it is still fresh under its Cache-Control max-age or s-maxage. Long-lived static files use versioned URLs, so they can be cached for a year and replaced by changing the URL.
On a miss, the PoP asks the regional Shield Cache rather than the origin. Many PoPs then share one copy, so the origin sees one request per object per region instead of one per PoP.
If the shield also misses, it fetches from the Origin Server or Origin Storage, and concurrent requests for the same object wait for that single fetch. Coalescing stops a popular object's expiry from sending thousands of identical requests to the origin.
When an object expires, the Edge Cache can keep serving the stale copy for a short grace period while one request revalidates it, using a conditional request that returns 304 if nothing changed. If the origin is down, stale content is served instead of an error.
Customers change cache rules in the Customer Console, and the Config API validates the change, stores a new version and asks the Certificate Manager for any new certificates. Versioned config can be rolled back if a rule breaks a site.
The new version is published on the Control Bus, and every PoP applies it within seconds. PoPs keep their last good config if the control plane is unreachable, so edge traffic never depends on it.
A purge by URL or by tag goes through the Purge Service and the bus to every PoP, which marks matching objects invalid. HTTP has no way to delete from caches, so a managed purge is how a customer removes a wrong or leaked file quickly.
Edge servers stream access logs to Traffic Analytics, where customers see hit ratio, bandwidth and errors per domain. Hit ratio is the number that shows whether cache rules are working.
The PoP Health Monitor probes each PoP and, when one fails, withdraws its route so traffic shifts to the next nearest PoP. Users see slightly higher latency instead of an outage.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (18 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Userslayer
- Anycast DNS: answers from the nearest PoP
- Browsers & Apps: request images, scripts, video
Edge PoPboundary
one of many points of presence
- Edge Cache: hot objects in RAM, the rest on SSD
- Edge Servers: TLS, cache key, serve or fetch
- PoP Load Balancer: spreads connections across edge servers
- WAF & Bot Rules: blocks attacks before cache lookup
Regional Tierlayer
- Shield Cache: one regional cache in front of origin
Customer Originboundary
- Origin Server: generates pages and API responses
- Origin Storage: static files and video segments (s3)
Control Planedomain
- Certificate Manager: issues and renews TLS certificates
- Config API: validates and versions configuration
- Config Store: per-domain rules and certificates (postgresql)
- Control Bus: config and purge fan-out to PoPs (kafka)
- Customer Console: cache rules, domains, purges
- Purge Service: accepts purge by URL, tag or prefix
Telemetrylayer
- Edge Log Stream: one record per request (kafka)
- PoP Health Monitor: withdraws routes from sick PoPs
- Traffic Analytics: hit ratio, bytes, status by domain (clickhouse)
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Video sharing platform (YouTube-style)How a video platform takes resumable uploads, encodes segments in parallel into several renditions, and serves them via a CDN with adaptive bitrate.
- Photo sharing platformHow a photo sharing platform takes uploads straight to object storage, resizes them in the background, and builds follower feeds from cached post ids.
- Music streaming serviceHow a music streaming service pre-encodes tracks into encrypted segments, checks rights before playback, and turns play events into royalties.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.