Bénéficiez de toutes les fonctionnalités d’un CDN moderne : une scalabilité transparente, une sécurité intégrée, un contrôle par programmation et une visibilité totale.
What Is CDN Architecture?
CDN architecture is the distributed network design that allows a content delivery network (CDN) to deliver websites, applications, APIs, video, images, and other digital content closer to users.
Instead of sending every request directly to a centralized origin server, a CDN routes requests through geographically distributed infrastructure at the network edge. Frequently requested content can be cached there, reducing the distance data travels and the amount of work required from origin infrastructure.
The design of a CDN - including its points of presence (POPs), caching model, routing, connectivity, security, and origin architecture - can significantly affect application performance, scalability, availability, and security.
CDN architecture explained
CDN architecture describes how a CDN's infrastructure and services are organized to receive, process, cache, secure, and deliver internet traffic.
A simplified CDN architecture looks like:
User → CDN edge → Origin
When a user requests a resource, the CDN directs the request to an appropriate edge location. If that location already has a fresh copy of the requested content in cache, it can return it without contacting the origin.
If the content isn't available, the CDN retrieves it from an upstream source, such as an origin server or another caching layer. The response may then be cached for subsequent requests.
A modern CDN architecture can include:
Points of presence (POPs)
Edge servers
Caches
Traffic-routing systems
DNS infrastructure
Load balancing
Origin servers
Origin shielding
Security services
Edge computing
Logging and observability
Together, these components create a distributed layer between users and application infrastructure.
What are the main components of CDN architecture?
Points of presence
A point of presence, or POP, is a physical location where a CDN operates network infrastructure. POPs are distributed geographically so requests can be handled closer to users rather than always traveling to a distant origin.
CDN providers take different approaches to network design. Some emphasize operating a very large number of locations, while others prioritize larger, higher-capacity POPs in strategic locations. As a result, POP count alone isn't necessarily a useful measure of CDN performance.
Edge servers
Edge servers operate within CDN POPs and handle requests from users. Depending on the CDN, an edge server may perform functions including:
Cache lookup
HTTP processing
TLS termination
Request routing
Security inspection
Edge logic
Logging
Moving these functions closer to users can reduce the work that needs to happen at the origin.
CDN cache
The cache temporarily stores eligible content at the edge. When the requested content is already available and fresh, the CDN can produce a cache hit and serve it directly. When it isn't available, a cache miss generally requires the CDN to retrieve the content upstream. Improving cache-hit ratio can reduce latency and origin load.
Origin infrastructure
The origin is the authoritative source from which the CDN retrieves content.
Origins can include:
Web servers
Cloud infrastructure
Object storage
Kubernetes applications
APIs
Load balancers
Multiple backend services
The CDN sits between users and these systems.
Routing and DNS
A CDN needs to direct users toward appropriate infrastructure. Providers can use technologies such as DNS and Anycast routing to steer traffic toward suitable edge locations. Routing decisions may account for network topology, availability, and other factors.
Security layer
Modern CDN architectures increasingly combine delivery and security at the edge.
Security capabilities can include:
DDoS mitigation
Web application firewall protection
Bot management
Rate limiting
TLS
API protection
Stopping unwanted traffic at the edge can prevent it from consuming origin resources.
How does CDN architecture work?
Consider a user requesting an image from an ecommerce site.
Step 1: The user makes a request
The browser requests the image from the website.
Step 2: Traffic reaches the CDN
The CDN's network architecture directs the request to an appropriate edge location.
Step 3: The edge checks its cache
The CDN determines whether a fresh copy of the image is already available. If it is, the image can be returned immediately from the edge.
Step 4: The CDN retrieves missing content
If the image isn't cached, the edge requests it from the origin or an upstream caching layer.
Step 5: The response is cached
If the response is cacheable, the CDN can temporarily store it according to its caching policy.
Step 6: Future users receive the cached copy
Subsequent requests can be fulfilled from the edge without repeatedly contacting the origin. At large scale, this process can eliminate enormous numbers of unnecessary origin requests.
What is a CDN edge architecture?
The edge refers to distributed infrastructure positioned closer to users than centralized application infrastructure. Traditional CDNs primarily moved static files such as images, JavaScript, CSS, and video closer to users. Modern edge architectures can do considerably more.
Depending on the platform, edge infrastructure can:
Cache static and dynamic content
Execute application logic
Inspect security threats
Modify HTTP requests and responses
Authenticate requests
Route traffic between origins
Process API requests
Generate responses
Collect real-time telemetry
This has expanded the CDN from a content-distribution layer into a broader application-delivery and computing platform.
Why is CDN architecture important?
The architecture underneath a CDN affects how effectively it can deliver and protect applications.
Performance
Serving content closer to users can reduce network latency and improve response times. Architecture also affects cache capacity, routing efficiency, connection reuse, and the amount of origin communication required.
Scalability
A CDN distributes requests across edge infrastructure rather than sending all traffic to the origin. This can help applications accommodate large audiences and sudden traffic spikes.
Availability
Distributed infrastructure can reduce reliance on individual servers or locations. Capabilities such as caching, stale-content serving, origin failover, and traffic routing can also improve application resilience.
Origin protection
A CDN can reduce the number of requests reaching backend infrastructure.Caching, request collapsing, origin shielding, DDoS protection, bot management, and rate limiting can all contribute to origin protection.
Security
An edge-based security architecture can detect malicious traffic before it reaches application infrastructure. This can be particularly useful during large DDoS attacks or automated attacks that would otherwise consume backend resources.
What is origin shielding in CDN architecture?
Origin shielding adds another caching layer between CDN edge locations and the origin.
A simplified architecture becomes:
User → Edge POP → Shield POP → Origin
Without shielding, multiple edge locations experiencing cache misses may independently request the same content from the origin. With shielding, those edge locations can request the content through a designated shield. If the shield already has the object, it can respond without involving the origin.
Origin shielding can help:
Increase cache efficiency
Reduce origin requests
Reduce origin bandwidth
Collapse duplicate requests
Protect backend infrastructure during traffic spikes
It can be particularly valuable when origin infrastructure is expensive, geographically distant, or sensitive to large numbers of concurrent requests.
What is the difference between centralized and distributed CDN architecture?
A centralized application architecture depends heavily on one or a small number of origin locations. Users located far from those origins may experience additional latency, and sudden traffic increases can place significant demand on centralized infrastructure.
A distributed CDN architecture introduces edge locations between users and origins.
Instead of:
Users around the world → Central origin
the architecture becomes:
Users → Nearby CDN edges → Origin when necessary
The origin remains important, but it doesn't need to participate in every request.
What is the difference between a traditional CDN and a modern CDN architecture?
Traditional CDNs were largely associated with caching and distributing static assets.
Modern CDN platforms can combine content delivery with:
Dynamic caching
Edge computing
Application security
API delivery
Bot management
DDoS protection
Traffic management
Real-time observability
The distinction between CDN, edge platform, and application-delivery infrastructure has consequently become less rigid.
A modern CDN can serve as an active layer through which application traffic is processed rather than simply a distributed collection of file caches.
What are common CDN architecture models?
Different providers and applications can use different designs.
Distributed edge caching
Content is cached across geographically distributed edge locations close to users. This is the foundation of conventional CDN delivery.
Tiered caching
Multiple caching layers are used between the user and origin. An edge cache might request content from a regional or shield cache before contacting the origin.
Multi-origin architecture
A CDN can route traffic to multiple backend systems. Organizations might use different origins for different content types, applications, geographic regions, or availability requirements.
Multi-CDN architecture
Some organizations use more than one CDN provider. Traffic-management systems can distribute or fail over traffic between CDNs. This can provide additional redundancy but introduces greater operational complexity.
Edge-computing architecture
Application logic executes directly on distributed edge infrastructure. This can reduce round trips to centralized infrastructure for workloads that benefit from processing close to users.
What are CDN architecture best practices?
Design caching intentionally
Determine which content can be cached and for how long. Static assets may support long TTLs, while rapidly changing content may require shorter TTLs or active cache invalidation.
Protect the origin
If traffic is intended to pass through the CDN, attackers shouldn't be able to bypass the CDN easily and attack the origin directly. Restrict origin access where possible.
Use origin shielding when appropriate
Shielding can reduce duplicate requests and improve cache efficiency, particularly for applications with many edge locations accessing a smaller number of origins.
Plan for origin failure
Consider how the application should behave when an origin becomes unavailable. Options can include multiple origins, failover, stale-content serving, or graceful degradation.
Optimize cache keys
A cache key determines which requests can share a cached response. Including unnecessary request characteristics can fragment the cache, while failing to include characteristics that actually change the response can cause incorrect content to be served.
Build security into the edge architecture
Combine CDN delivery with appropriate DDoS protection, WAF, bot management, rate limiting, and TLS controls.
Monitor edge and origin performance
Track metrics like:
Cache-hit ratio
Origin traffic
TTFB
Error rates
Request volume
Geographic performance
Purge activity
Security events
Observability can reveal whether the architecture is actually delivering the intended performance and resilience benefits.
How does Fastly approach CDN architecture?
Fastly's CDN architecture is built around strategically located, high-capacity points of presence connected to its global edge cloud platform. Rather than treating POP count as the primary measure of network quality, Fastly's architecture emphasizes powerful edge locations with substantial caching and processing capacity.
This design is intended to keep more content at the edge and give developers greater control over how requests, responses, and cached objects are handled.
What Fastly capabilities support modern CDN architecture?
High-capacity edge network
Fastly operates a globally distributed edge network designed to process and deliver large volumes of traffic. Its POP architecture supports CDN caching, application delivery, security, and edge computing on the same broader platform.
Dynamic content caching
Fastly allows organizations to cache more than conventional static assets. With appropriate cache policies, dynamic and event-driven content can also be cached at the edge, reducing trips to application origins.
Instant Purge™
Caching content for long periods can improve performance, but applications also need a way to update content when it changes. Fastly's Instant Purge™ allows cached objects to be invalidated rapidly across the network. Organizations can purge individual URLs or groups of related content.
This allows applications to combine longer cache lifetimes with greater control over freshness.
Origin Shield
Fastly Origin Shield allows organizations to designate a Fastly POP as an additional caching layer between edge locations and the origin.
The resulting architecture can look like:
User → Fastly edge POP → Fastly shield POP → Origin
Shielding can reduce the number of requests reaching origin infrastructure and improve overall cache efficiency.
Edge computing
Fastly Compute allows developers to run application logic on Fastly's edge infrastructure. This enables architectures in which the edge does more than retrieve and cache content. Applications can process requests, make routing decisions, interact with backend services, and generate responses closer to users.
Integrated application security
Fastly's platform can combine delivery with security capabilities such as Next-Gen WAF, Bot Management, DDoS Protection, and rate limiting. Applying security controls at the edge can stop unwanted traffic before it consumes application and origin resources.
Real-time observability
Fastly provides real-time logging and observability capabilities that allow organizations to understand how traffic moves through their CDN architecture. This can help teams investigate performance problems, monitor cache behavior, analyze errors, and respond to security events.
How can Fastly help organizations build a CDN architecture?
Fastly can act as a distributed delivery, security, and computing layer between users and application infrastructure.
A Fastly-based architecture can take a form like:
Users → Fastly edge → Fastly security and caching → Origin Shield → Application or storage origin
Depending on the workload, organizations can use Fastly to:
Cache content closer to users
Reduce origin requests
Rapidly invalidate cached content
Deliver static and dynamic experiences
Protect web applications and APIs
Mitigate DDoS and bot traffic at the edge
Execute application logic with Fastly Compute
Route requests to backend services
Gain real-time visibility into traffic
Improve application resilience during traffic spikes
The right CDN architecture ultimately depends on the application. Geographic audience, traffic volume, cacheability, origin design, security requirements, APIs, and availability goals should all influence the design.
The central principle remains straightforward: move delivery, processing, and protection closer to users while reducing unnecessary dependence on centralized origin infrastructure. Fastly's edge cloud platform is designed to provide that distributed layer while giving development and security teams control over how their applications behave at the edge.