# CDN vs Cache

> A CDN is a geographically distributed delivery network that often caches HTTP content near users; a cache is the broader mechanism for reusing stored results. Use a CDN to reduce user-to-origin distance and origin traffic, and an application cache to avoid repeated database reads or computation. Most media-heavy systems need both.

Source: https://sysround.com/compare/cdn-vs-cache
Updated: 2026-11-05


## Side by side

| | CDN | Cache |
|---|---|---|
| What it is | Edge delivery network with caching capabilities | Reusable data or results stored for faster access |
| Typical placement | Edge locations near users | Inside a process or near application servers |
| Typical content | Images, video segments, assets, cacheable HTTP responses | Records, query results, sessions, computed values |
| Primary benefit | Less network distance and origin traffic | Less database work and repeated computation |
| Access interface | HTTP requests through an edge endpoint | Application reads and writes through a cache API |
| Cache keys | Configured URL, query, header, or cookie dimensions | Application-defined keys and namespaces |
| Freshness controls | HTTP cache policies, versioned URLs, purges | TTL, explicit invalidation, update or refill logic |
| Miss path | Fetch from an upstream cache or origin | Application loads from storage or computes a result |
| Capacity and cost | Delivery traffic, requests, origin fetches, provider terms | Memory, nodes, replication, and operational overhead |

## The differences that matter

These are not mutually exclusive categories. A CDN commonly contains caches, but also handles request routing, TLS termination, and other delivery functions. Here, “cache” means an application-side cache, such as an in-process cache or a shared key-value cache.

Placement determines which latency you remove. A CDN hit can avoid the trip to the application's region entirely. An application-cache hit still requires reaching the application, but avoids a database query or expensive computation. A regional cache alone does not solve long-distance media delivery.

The cached unit changes the design. A CDN usually reuses an HTTP response or media segment, while an application cache can reuse one database record across many different responses. Personalized pages may have little shared response reuse even when their underlying product or profile records are highly reusable.

Freshness requires separate policies at each layer. Versioned asset URLs work well for immutable files; mutable API responses need bounded TTLs, revalidation, or purges. Updating an application cache does not invalidate an already cached CDN response, and a CDN purge does not repair stale application data.

Failure and security boundaries differ. An edge miss can push traffic back to the origin, while an application-cache outage can overload the database. Shared edge caching also requires explicit rules for authorization and response variation so one user's private response is never served to another.

## Choose CDN when

- Users are geographically distributed and fetch the same images, scripts, downloads, or video segments.
- Large response bodies make origin bandwidth and repeated delivery a major capacity concern.
- Public HTTP responses can be shared safely with an explicit freshness policy.
- Immutable, versioned objects can remain cached for long periods without serving an outdated version under the same URL.

## Choose Cache when

- Repeated database lookups or computations dominate backend latency and load.
- Requests are personalized, but many requests reuse the same underlying records.
- The application needs fine-grained keys, explicit invalidation, or cached intermediate results.
- Reuse is concentrated within one service or region, so an in-process or shared regional cache addresses the bottleneck.

## Worked example: A photo service needs two caching layers

Suppose a photo service receives 20,000 image requests per second, averaging 200 KB each. That is roughly 4 GB/s of image payload before protocol overhead. If the CDN achieves an assumed 95% byte hit rate, origin image delivery falls to about 200 MB/s; actual results depend on geography, popularity, and expiration. Separately, the service handles 5,000 metadata reads per second. An application cache with an assumed 90% request hit rate reduces database reads to roughly 500 per second, excluding other traffic. Use versioned URLs for image variants and a separate freshness policy for captions. Neither layer replaces authorization checks for private photos.

## In the interview

- Clarify the comparison first: a CDN is not the opposite of a cache. State that you are comparing edge HTTP caching with application-side caching.
- Draw both read paths and mark what each hit avoids. Expect questions about origin bandwidth, database QPS, geographic latency, and cacheable traffic.
- Define the cache key and authorization boundary. Explain which query parameters, headers, or user scopes affect the response without creating unnecessary variants.
- Give each data class a freshness budget. Interviewers may probe deletion, permission revocation, stale reads, and how changes propagate through multiple cache layers.
- Walk through a cold start or outage. Discuss request coalescing, bounded retries, origin protection, and whether stale data is safe to serve.

## Common mistakes

- Presenting CDN and cache as competing products rather than different layers that often work together.
- Assuming a CDN caches every response automatically or cannot cache API responses.
- Caching personalized or permission-sensitive responses under a shared key without a safe authorization design.
- Quoting one global hit rate while ignoring regional cache populations, response sizes, and the backend work caused by misses.

## Interview questions where it comes up

- [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): Separate CDN delivery of video segments from application caching of metadata and other backend reads.
- [Design Instagram](https://sysround.com/questions/design-instagram): Use edge caching for image variants while separately designing feed and metadata caches.
- [Design TikTok](https://sysround.com/questions/design-tiktok): Distinguish globally cached video delivery from personalized feed retrieval and freshness-sensitive feedback.
- [Design Google Photos](https://sysround.com/questions/design-google-photos): Explain how cached private media remains protected when album access is revoked.
- [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): Compare caching public page responses at the edge with caching document records while preserving edit freshness and permissions.

## FAQ

### Is a CDN the same as a cache?

No. A cache stores reusable data or results, while a CDN is a distributed delivery network that commonly uses caches at edge locations. Caches also exist in browsers, application processes, databases, and shared backend services.

### Can a CDN replace Redis or an application cache?

Usually not, because they avoid different work. A CDN can serve eligible HTTP responses without reaching the application, while an application cache can reuse records or computed values across many response types. A CDN may remove the need for some response caching, but not every backend caching use case.

### Can a CDN cache dynamic API responses?

Yes, if the response is cacheable under the CDN's configuration and has a safe cache key and freshness policy. Public catalog or weather responses are possible candidates. Personalized responses require careful isolation, and responses that must reflect current authorization or inventory may need to bypass caching or validate against authoritative state.

## Related concepts

- [Content delivery networks (CDN)](https://sysround.com/concepts/cdn)
- [Caching strategies](https://sysround.com/concepts/caching-strategies)
- [Cache invalidation](https://sysround.com/concepts/cache-invalidation)
- [Cache stampede and thundering herd](https://sysround.com/concepts/cache-stampede)
- [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.