Why CDN Isn’t Always Faster: A Deep Dive into Architecture, Caching, and Origin Pull

Introduction

Developers often hear about CDN (Content Delivery Network) as a speed‑up solution, but the reality is more nuanced. This guide walks through the entire CDN chain, its working principles, origin‑pull mechanism, and when CDN may or may not bring benefits.

From Traditional Storage to Object Storage + CDN

For textual data we usually store it in MySQL and optionally cache with Redis . When the data becomes large binary objects (images, videos, etc.), a relational database is no longer suitable; instead we use an object storage service such as Amazon S3 or Alibaba Cloud OSS. The cache layer for such objects is provided by a CDN, which can be thought of as the caching counterpart of object storage.

CDN Working Principle

When a browser requests an image URL like https://cdn.xiaobaidebug.top/1667106197000.png, the following steps occur:

DNS lookup for cdn.xiaobaidebug.top obtains the IP address.

The DNS resolver follows a series of CNAME records (e.g., cdn.xiaobaidebug.top.w.kunlunaq.com) that point to the CDN provider’s DNS scheduling system.

The provider returns the IP of the nearest CDN edge node based on the client’s IP, ISP, and geographic location.

The client connects to that edge node and requests the resource.

If the edge node has the object cached, it returns it directly. Otherwise it performs an origin pull from the object storage.

DNS Record Types

Typical domain names resolve to an A record (direct IP). CDN domains first resolve to a CNAME that points to the provider’s DNS, which then returns a nearby edge node IP.

dig +trace xiaobaidebug.top
;; ANSWER SECTION:
xiaobaidebug.top. 600 IN A 47.102.221.141

dig +trace cdn.xiaobaidebug.top
cdn.xiaobaidebug.top. 600 IN CNAME cdn.xiaobaidebug.top.w.kunlunaq.com.
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.243

Origin Pull (回源)

The first request for a file that is not cached triggers a pull from the object storage (the true data source). The CDN stores the object for subsequent requests, which then become cache hits.

Cache miss can also happen when the cached entry expires or when the CDN is explicitly instructed to refresh.

Detecting Origin Pull

Using tools like Postman or curl, you can inspect the response header X-Cache: MISS TCP_MISS – cache miss, CDN fetched from origin. HIT TCP_MEM_HIT – cache hit, served from CDN.

When CDN May Not Help

If the service runs inside a private network and the files are rarely requested repeatedly, adding a CDN introduces an extra network hop without the benefit of “nearby edge nodes.” In such cases the miss rate can be very high (e.g., >90%), making the overall latency worse.

Internal services where the client and storage are in the same data center.

Files that are accessed only once or infrequently.

Best Practices

Pre‑warm hot objects by issuing requests before a major release.

Increase cache TTL for frequently accessed assets.

Use gray‑release or staged rollout to gradually populate CDN caches.

Monitor X-Cache statistics to keep the origin‑pull ratio low.

Summary

Textual data typically uses MySQL + Redis; binary objects should use object storage + CDN.

Cache miss (origin pull) makes CDN slower than direct access.

CDN shines when it can serve the same file repeatedly to users worldwide, but offers little benefit for internal, low‑traffic, or one‑time‑access scenarios.