CDN and Edge Caching

Build the mental model

A prior lesson covered application-level caching — storing computed results in memory or Redis to avoid redoing work on the same server. CDN and edge caching solves a different problem: physical distance. Even a perfectly fast origin server in, say, the US takes real time to answer a request from a user in Yangon, because network packets are bound by the speed of light and the number of network hops — no amount of server-side optimization removes that geography. A CDN solves this by deploying edge servers in many regions worldwide, each holding a cached copy of static (and sometimes dynamic) content; a user's request gets routed to the nearest edge server rather than crossing oceans to the origin, cutting round-trip latency dramatically and reducing load on the origin since it only needs to serve edge servers, not every individual user. The trade-off is freshness: an edge cache can serve slightly stale content until it re-validates with the origin (governed by a TTL or cache-invalidation signal), so CDNs are best suited to content that doesn't change every second.

Connect it to a real scenario

The Tutorial Platform serves lesson videos, images, and static assets to learners across many countries. Without a CDN, a learner in Yangon watching a video hosted on a single US-based origin server suffers a multi-hundred-millisecond round trip per request; with a CDN, the video is cached on an edge server in or near Southeast Asia, and subsequent viewers in the region get near-local latency. Lesson text content, which changes when an instructor edits it, uses a short TTL so edges refresh quickly, while immutable assets like course icons and video files use a long TTL since they rarely if ever change — matching CDN caching aggressiveness to how often each asset type actually changes.

• CDNs are network-level, geography-driven caching, distinct from application-level caching.
• Edge servers cache content close to users geographically, dramatically cutting round-trip latency.
• The CDN trade-off is freshness — edge caches can briefly serve stale content until they re-validate with the origin.

Try the working example

WITHOUT CDN                              WITH CDN
                                          +------------------+
+------------------+                     |  Origin Server   |
|  Origin Server    |                    |     (US)         |
|     (US)          |                    +------------------+
+------------------+                        /       |      \
   ^      ^      ^                    edge sync  edge sync  edge sync
   |      |      |                       /          |          \
   |      |      |                +--------+   +--------+   +--------+
 Yangon  Berlin  Tokyo             | Edge   |   | Edge   |   | Edge   |
 (280ms)(120ms)(180ms)             | SE Asia|   | Europe |   | Japan  |
                                    +--------+   +--------+   +--------+
                                       ^              ^            ^
                                       |              |            |
                                     Yangon         Berlin        Tokyo
                                     (15ms)         (10ms)       (8ms)

Latency without CDN: 120-280ms (crosses ocean every request)
Latency with CDN: 8-15ms (served from nearby edge)

The diagram shows that without a CDN every request crosses an ocean to the origin with high latency, while a CDN serves from a nearby edge with far lower latency.

Wikipedia — Content delivery network — System Design