What is a CDN (Content Delivery Network)?

A CDN is a network of distributed servers that caches content close to users, so pages and files load fast everywhere. Physics is the problem it solves: a request from São Paulo to a server in Frankfurt pays the round trip in latency, every time. A CDN answers from São Paulo instead — and one clarification saves endless confusion: it complements your hosting, it never replaces it.

Key takeaways

The knobs that make it work

The whole caching contract fits in one HTTP header — and it’s the single most under-explained piece of every CDN explainer:

# The origin's instruction to every cache between it and the user:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → any cache may store this
  max-age=300             → browsers: fresh for 5 minutes
  s-maxage=86400          → CDN edges: fresh for 24 hours
  stale-while-revalidate  → serve stale instantly, refresh in background

# The other strategy: never expire, never purge — version the filename
/_assets/app.3f9c1b.css   → cache "forever"; a new build means a new URL

Where files come from in an app matters too — on a managed backend, an upload returns a delivery-ready URL with the caching story already sane:

// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL

// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL

// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
  if case .success(let saved) = result {
    print(saved.url ?? "") // CDN-backed, cache-friendly URL
  }
}

// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
  if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}

Anatomy of a request

The vocabulary in one pass: the origin is your actual server — the source of truth. A PoP (point of presence) is a CDN data-center location; edge servers are the caching machines inside it. The cache-hit ratio — the share of requests answered without touching the origin — is the metric the whole exercise optimizes, and the levers are the headers above. What improves for users is TTFB (time to first byte) and, when full pages are edge-cached, the loading metrics that follow from it.

CDN vs. web hosting vs. edge computing

The MDN definition adds the caveat vendor pages skip: third-party CDN scripts are a supply-chain dependency (integrity attributes exist for a reason), and an extra DNS lookup to a CDN can even cost time on a first visit — leverage, not magic.

Common use cases

• Static assets at scale. CSS, JavaScript, fonts, images — fingerprinted filenames plus long TTLs turn repeat visits into pure edge traffic.
• Media and downloads. Video segments and large files, where origin bandwidth would be the bill and the bottleneck.
• Global audiences. The same page served under 100 ms on four continents without running servers on four continents.
• Traffic spikes and launches. The edge absorbs the surge; the origin sees a fraction of it.
• Security posture. Origin hidden behind a reverse proxy, TLS terminated at the edge, volumetric attacks dissipated across the network.

Do you need a CDN? A decision matrix

The honest row nobody prints: on a low-traffic site, cached copies expire between visitors, every request is a miss, and the CDN adds a hop for nothing. Distance and volume are the inputs; without either, fix something else first.

Limitations and trade-offs

• Stale content is the default failure. Long TTLs mean yesterday’s file served confidently today; the cure is purging (slow, per-CDN) or versioned filenames (better).
• Cache invalidation is genuinely hard. It’s one of the two famous hard problems for a reason — design URLs so you rarely need it.
• Dynamic content resists caching. Per-user responses can’t be shared; acceleration and edge logic help, but the origin still does the work.
• A dependency in the critical path. CDN outages are internet-weather events; when the edge is down, “your” site is down.
• Debugging gets a layer. Which cache served this? With which headers? Cache-status headers and per-edge behavior become part of your observability surface.

CDNs and Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The CDN story is built into the file layer: upload through any SDK (the tabs above) and the returned URL is delivery-ready — stable, cacheable, and independent of your API’s dynamic traffic, which keeps the cacheable and uncacheable halves of your app cleanly separated. Web frontends hosted on Back4app Containers sit naturally behind any CDN, with the classic pattern — long-lived fingerprinted assets, short-lived HTML — configured in one header.