CDN and Latency in System Design
A CDN, or Content Delivery Network, is a set of servers placed in many locations around the world. These servers sit closer to users than the main application server, which we usually call the origin. The basic job of a CDN is to answer requests from nearby locations instead of always sending them to the origin. If the same content is requested again and again, the CDN keeps a copy and serves it directly.
In real systems, a CDN does more than store files. It often handles TLS, compression, redirects, basic request filtering, and sometimes security rules. Platforms like Cloudflare, Akamai, and Fastly all follow this same idea, even though their features differ.
From a system design point of view, a CDN is not a frontend trick. It is an architectural layer that decides where work happens.
Latency is mostly about distance. If your origin server runs in one region and your users are spread across the world, every request that travels back to the origin adds delay. Without a CDN, even simple requests must cross long network paths. With a CDN, many requests are answered by an edge server that is physically closer to the user. This shortens the network path and reduces response time.
But the real architectural value is not just speed. A CDN changes the pressure on the system. When content is served from the edge, the origin backend does less repeated work. This makes the system more stable and predictable, especially under load.
That is why senior engineers think of CDNs as part of system design, not just performance tuning.
Why Is a CDN Important?
A CDN delivers value in a few fundamental ways, all tied to where requests are answered and how often the origin is involved.
Lower latency
The most visible benefit is latency reduction. When content is served from a nearby edge location, requests avoid long cross-continent network paths. Fewer hops and shorter physical distance usually mean faster responses for users.
Origin protection
Once popular content is cached at the edge, the origin no longer needs to serve the same request repeatedly. This protects application servers and databases from unnecessary load and reduces the risk of cascading failures during high traffic.
Better handling of traffic spikes
Marketing campaigns, product launches, or viral moments often generate massive repeated requests for the same resources. A CDN absorbs this repetition at the edge, allowing the origin to focus on truly dynamic or uncached work. In many cases, this is the difference between a stable system and an overloaded one.
Shorter network paths
Users receive content from an edge location close to them instead of always reaching back to a single primary region. This improves performance even when the origin itself is healthy.
Improved global experience
Users far from the primary deployment region see the biggest gains. With a well-configured CDN, performance feels more consistent across geographies instead of degrading with distance.
In short, a CDN is not just a performance optimization. It is a reliability and scalability layer that changes how load, latency, and bursts are handled across the system.
How Does a CDN Work?
A CDN works by moving content closer to users and reducing how often requests reach the origin server. Here is the step-by-step flow of what happens when a user makes a request.
CDN request flow
Step 1
User request
Step 2
DNS → nearest edge
Step 3
Edge cache lookup
Cache hit
Edge returns content immediately. Low latency, no origin involved.
Cache miss
Edge forwards to origin, caches the response, then serves the user.
Origin
On cache miss only
Future requests
Served from edge
Detailed steps
User makes a request
A user opens a website or requests an asset (HTML, image, video, API response). The request goes to the domain configured with a CDN (for example, cdn.example.com).
DNS routes the request to the nearest edge
DNS resolution points the user to the closest or best-performing CDN edge location based on geography, latency, and network conditions. The user does not directly contact the origin server.
Edge cache lookup (cache hit vs cache miss)
Cache hit: the requested content is already cached at the edge, so the edge immediately returns the response to the user with very low latency and no origin involvement. Cache miss: the edge does not have the content (or it expired), so the edge forwards the request to the origin server.
Origin fetch (only on cache miss)
The origin server generates or returns the requested content. The CDN edge sends the response back to the user and stores a copy in its cache based on cache rules and headers. Future requests for the same content can now be served directly from the edge.
Caching rules control behavior
Caching is controlled by HTTP headers (Cache-Control, Expires, ETag), CDN configuration (TTL, cache keys, bypass rules), and content type (static vs dynamic). This determines what gets cached, for how long, and when content must be revalidated with the origin.
Revalidation and freshness
When cached content expires, the edge may revalidate with the origin using conditional requests. If unchanged, the edge refreshes the TTL without downloading the full response. If changed, a new version is fetched and cached. This keeps content fresh without unnecessary data transfer.
Handling traffic spikes
When many users request the same resource, the first request may hit the origin, but thousands or millions of subsequent requests are served from edge caches. This prevents the origin from being overwhelmed during spikes.
Global consistency
Different regions have their own edge caches. Users in Asia, Europe, and the US are all served from nearby locations instead of a single central server.
How the Request Path Changes with a CDN
In a system without a CDN, every request follows the same path. A user asks for a page or an asset, the request travels all the way to the origin region, the backend processes it, and the response comes back across that same distance. This is simple, but it means the origin is involved in every request and the longest network path is paid repeatedly.
Introducing a CDN changes that path. Requests are routed to an edge location close to the user. The first request for a resource may still reach the origin, but once the response is cached, later requests are answered at the edge. In simple terms, this moves reusable traffic from the origin to the edge. The impact is less bandwidth leaving the origin, less repeated computation, and lower tail latency because many requests no longer traverse long network paths.
This is not an optimization at the margins. It changes where work happens.
What Content Should a CDN Cache?
The instinctive starting point is static assets, and that is correct. JavaScript bundles, stylesheets, images, fonts, downloads, and media segments are natural fits for edge delivery. But mature systems rarely stop there.
Public HTML pages, rendered landing pages, documentation, pricing pages, and anonymous API responses are often requested far more frequently than they change. When many users can safely receive the same response for some period of time, the edge is usually the right place to serve it. Whether the content is generated dynamically at the origin is less important than whether the result is reusable.
Content that is deeply personalized, tied to authentication state, or highly time-sensitive typically needs stricter handling. In those cases, the cost of a wrong response is higher than the benefit of caching, so the request remains on the origin path or uses short-lived revalidation.
| Content category | Examples | Good edge strategy |
|---|---|---|
| Public static assets | JS bundles, CSS, images, fonts, downloadable files, media segments. | Cache aggressively with long TTLs, especially when assets are versioned. |
| Public but frequently updated content | Landing pages, docs, pricing pages, anonymous API responses, product catalog pages. | Cache with shorter TTLs, explicit revalidation, or purge on publish. |
| Private or user-specific content | Account pages, dashboards, user carts, authenticated API responses. | Usually bypass shared edge cache unless you have carefully scoped private caching rules. |
| Dynamic but reusable for short windows | Popular feeds, search suggestions, public availability results, rapidly refreshed counters. | Use short TTLs or stale-while-revalidate to reduce origin pressure without hiding updates for long. |
Cache Correctness Is the Real Work
Turning caching on is easy. Keeping it correct is the hard part.
Every cached response represents a promise: that serving this representation again is still valid. Breaking that promise by serving stale or user-specific data is worse than being slow. That is why experienced teams think about TTLs, revalidation, invalidation, and cache keys as part of the system's data model, not as infrastructure defaults.
Decisions about how headers, cookies, and query parameters affect cache identity must be explicit. Some content is cached aggressively. Some is revalidated frequently. Some bypasses the cache entirely. Some is purged in response to publishing or configuration changes. The system works because these rules are deliberate and grounded in the meaning of the content, not because the cache hit rate looks good on a dashboard.
Fast but wrong is still wrong.
TTL
The simplest rule. Content expires after a defined time and the edge must revalidate or refetch it.
Revalidation
The edge checks whether content changed using validators such as ETag or Last-Modified before downloading a full fresh copy.
Purge / invalidation
You explicitly remove content from caches when the origin changes and waiting for TTL expiry would be too slow or risky.
Cache tags / surrogate keys
Instead of purging one URL at a time, you purge logical groups of content that share a page fragment, product, category, or document set.
How to Measure Whether a CDN Is Working
A CDN strategy should not be judged only by whether the site feels faster from one laptop. Strong teams monitor whether the edge is actually absorbing origin work, whether users in far regions see lower latency, and whether update propagation is safe enough for the content.
| Metric | Why it matters |
|---|---|
| Cache hit ratio | Shows how much traffic is being served from the edge instead of the origin. |
| Origin offload | Measures how much backend work, bandwidth, and request volume the CDN is absorbing. |
| TTFB / latency by geography | Reveals whether distant users are actually benefiting from edge delivery. |
| Purge propagation time | Tells you how quickly corrected content reaches all regions after an update. |
| Error rate on edge vs origin | Helps separate caching, routing, and origin failure modes during incidents. |
Why a CDN Also Protects the Origin
Latency improvements are the most visible benefit of a CDN, but origin protection is just as important. When the same public resource is requested tens or hundreds of thousands of times, the real question is whether the backend should be involved every time. In most systems, the answer is no.
By absorbing repeated requests at the edge, a CDN reduces pressure on application servers, internal caches, and databases. This lowers infrastructure cost, reduces the risk of cascading overload during traffic spikes, and keeps the backend focused on work that truly must be generated live. It is one of the cleanest examples of using architecture to remove unnecessary work from a system.
A well-designed CDN setup is not a performance trick. It is a structural decision about where load, risk, and responsibility should live.
How a CDN Helps with Security
A CDN is primarily a delivery and edge-caching layer, but in production systems it often becomes an important part of the security posture because it sits in front of the origin.
DDoS absorption
Because traffic first lands at the edge, a CDN can absorb and distribute large request floods before they all converge directly on the origin.
TLS termination
Many CDNs terminate TLS at edge locations, reducing connection cost close to users and simplifying certificate operations across regions.
WAF and edge filtering
CDNs often provide rate limiting, bot filtering, IP rules, and WAF enforcement before requests reach backend services.
Not a complete security boundary
A CDN helps at the edge, but it does not replace secure origin design, authentication, authorization, private-network controls, or application-level validation.
CDN vs Nearby Concepts
CDN questions often get confused with other infrastructure layers. Interviewers usually want to know whether you can place each one in the request path clearly.
CDN vs browser cache
Browser cache is private to one user and device. CDN cache is shared across many users and served from distributed edge servers.
CDN vs reverse proxy
A reverse proxy typically sits in front of the origin in a smaller number of locations. A CDN is globally distributed and optimized for edge delivery.
CDN vs load balancer
A CDN reduces how often requests need the origin. A load balancer distributes the origin traffic that still has to reach live application servers.
CDN vs application cache
Application caches reduce repeated work inside the backend stack. CDNs remove repeated public traffic before it reaches that stack at all.
CDN Benefits and Trade-offs
| Benefit | Effect | Trade-off |
|---|---|---|
| Lower latency | Content is served from a geographically closer edge location instead of a distant origin, reducing network round trips and response time. | Benefits depend on correct caching and routing. Poor cacheability or misconfigured rules limit latency gains. |
| Origin protection | Repeated requests are absorbed at the edge, reducing load on application servers, internal caches, and databases. | Cold caches, short TTLs, or weak invalidation strategies can still push high traffic back to the origin. |
| Traffic spike handling | Popular resources can withstand sudden demand surges because edges serve most of the repeated traffic. | Dynamic and personalized traffic still requires sufficient origin capacity and scaling plans. |
| Operational features at the edge | TLS termination, compression, redirects, WAF rules, and request filtering can be handled closer to users. | Edge misconfiguration can introduce subtle bugs, unexpected caching behavior, and harder production debugging. |
How Engineers Choose CDN Behavior
There is no single “best” CDN configuration. Real systems choose differently depending on whether the priority is lower latency, higher cache hit ratio, safer dynamic delivery, or stronger origin protection during spikes.
Goal
Minimize global latency
Favor broad edge presence, strong routing, and edge termination close to users.
Goal
Maximize cache hit ratio
Use good cache keys, long-lived versioned assets, and purge workflows that support aggressive caching.
Goal
Support dynamic workloads safely
Use short TTLs, revalidation, and explicit rules for public vs private responses.
Goal
Protect the origin during spikes
Identify the highest-volume reusable traffic and ensure it can be served from the edge before launch events.
Common CDN Providers and Where They Fit
Most system design interviews do not expect a vendor comparison, but it helps to know the common names and the general contexts where teams encounter them.
Cloudflare
Popular when teams want broad edge reach plus integrated security and developer-friendly edge tooling.
Akamai
Common in large enterprise delivery and security-heavy environments with global traffic at scale.
Fastly
Often chosen when teams care deeply about programmable edge behavior, caching control, and fast purge workflows.
Amazon CloudFront
A natural fit for workloads already centered in AWS and closely tied to S3, ALB, or other AWS services.
Interview prep
Common Interview Questions
These are the CDN questions that come up most often in system design and senior backend interviews, along with the signal interviewers are usually looking for in your answer.
What problem does a CDN actually solve?
What interviewers are testing
Interviewers want to see whether you understand that a CDN is not just about speed. A strong answer explains reduced latency, origin protection, and removal of repeated work from backend systems.
How does a CDN change the request path?
What interviewers are testing
This tests architectural thinking. The expected explanation is the shift from origin-first to edge-first delivery for cacheable content, and why that matters for tail latency and backend load.
What types of content should be served from a CDN?
What interviewers are testing
The goal here is judgment. Good answers talk about reuse and correctness, not just “static files.” Public pages, anonymous APIs, and rendered content are valid candidates if responses are safe to share.
What should not be cached at the edge?
What interviewers are testing
Interviewers want risk awareness. Personalized, authentication-dependent, security-sensitive, or highly volatile data should be discussed, along with why caching it could be dangerous.
How does a CDN protect the origin?
What interviewers are testing
This tests scalability reasoning. The key idea is that repeated requests should not repeatedly hit application servers, caches, or databases, especially during spikes.
What happens on a cache hit vs a cache miss?
What interviewers are testing
This checks fundamentals. You should clearly explain edge cache lookup, origin fetch on miss, cache population, and how future requests benefit.
How do TTLs and cache invalidation work?
What interviewers are testing
This is a depth question. Interviewers are looking for awareness that cache correctness is hard, and that TTLs, purges, and revalidation are design decisions, not defaults.
Why is cache invalidation considered hard?
What interviewers are testing
A strong answer mentions serving stale or incorrect data, coordinating updates across regions, and the trade-off between freshness and performance.
Can dynamic content be served via a CDN?
What interviewers are testing
This tests maturity. The expected answer is “yes, sometimes,” with examples like short-lived caching, revalidation, edge-side includes, or anonymous API responses.
How does a CDN help during traffic spikes?
What interviewers are testing
Interviewers want real-world thinking. You should explain how popular content is absorbed at the edge, reducing the blast radius on the origin during launches or viral events.
What are the risks of using a CDN?
What interviewers are testing
This tests balance. Good answers mention misconfiguration, debugging complexity, stale data, and false confidence that the CDN removes the need for origin capacity planning.
How does a CDN affect system reliability?
What interviewers are testing
This checks whether you see CDNs as a reliability layer. The right framing is reduced backend load, fewer cascading failures, and better isolation during traffic bursts.
How do headers like Cache-Control affect CDN behavior?
What interviewers are testing
This tests protocol knowledge. You should mention how cacheability, TTLs, and revalidation are driven by response headers and CDN rules together.
What is the difference between browser cache and CDN cache?
What interviewers are testing
Interviewers want clarity. A good answer contrasts client-side caching with shared, geographically distributed edge caching.
When would you avoid using a CDN?
What interviewers are testing
This tests restraint. Strong answers explain cases where correctness, personalization, or rapid change outweigh caching benefits.
Next topic
Continue the system design path
Resilient Systems
A CDN helps when the same response can be reused near users. When systems need services to stay healthy under failure, degrade gracefully, and protect critical traffic paths, resilient systems become the next important architectural topic.
Go to Resilient Systems