Are CDNs Right for Dynamic APIs? Distinguish Caching From Dynamic Acceleration

Our API returns dynamic data, so we probably can't use a CDN, right?

This is something often said when discussing API performance. It sounds reasonable, but it conflates two different things:Delivering API requests through a CDN does not mean API responses must be cached.

Endpoints such as product lists, public configurations, exchange rate snapshots, and article data may be suitable for short-term caching; user balances, order status, login information, and admin backend data generally cannot enter a shared cache. But even with no caching at all, API requests can still pass through CDN nodes to improve the access path through HTTPS offload, connection reuse, intelligent routing, security protection, and edge connectivity.

So the real question for dynamic APIs and CDNs is not 'Can dynamic content pass through a CDN?' but:

• Which responses can be shared by different users;

• Which responses must go back to origin every time;

• Even without caching, can the CDN improve the network path from users to the origin;

• Can the cache key correctly distinguish language, region, parameters, and user state;

• What impact will stale data have after cache invalidation;

• Could a misconfiguration leak user data?

Until these questions are answered, simply choosing to 'cache everything' or 'cache nothing' may push the result to the other extreme.

First distinguish three things: API caching, dynamic acceleration, and edge computing

Many CDN providers offer static acceleration, dynamic acceleration, edge functions, and API protection at the same time. The names look similar, but they do not solve exactly the same problems.

APIs can use only one of these approaches or combine them.

For example, an ecommerce site might configure it as follows:

• Product category endpoint: cache for 120 seconds;

• Product detail endpoint: cache for 30 seconds, with inventory fields fetched separately in real time;

• User shopping cart: does not enter shared cache, uses dynamic acceleration;

• Login endpoint: not cached, but uses CDN for WAF, rate limiting, and bot protection;

• Regional configuration endpoint: edge functions return different versions based on country;

• Checkout and payment endpoints: go back to origin every time, with full logs and risk control checks retained.

Therefore, 'putting APIs behind a CDN' is not a simple switch, but a matter of defining rules separately for different endpoints.

What is the point of routing dynamic APIs through a CDN if they are not cached?

If every request ultimately has to go back to the origin, does the CDN just add another layer?

Not necessarily.

When users access the origin directly, the path is usually:

用户 → 公网线路 → 源站

After adding a CDN, a dynamic request may become:

用户 → 附近CDN节点 → CDN骨干或优化线路 → 源站

Even if responses are not cached, the CDN may still play a role in the following areas.

Establish connections nearby

Users first connect to a closer edge node, and the TLS handshake is completed at the edge. The CDN then accesses the origin through an already established or reused connection, reducing the overhead of re-establishing long-distance connections for every request.

The size of the effect depends on user location, origin location, network quality, and CDN implementation. If users and the origin are already in the same city, adding a CDN layer may not be faster; the improvement may be more noticeable across countries, across ISPs, or on unstable links.

Connection reuse

APIs are usually not requested just once. A page or app may call multiple endpoints in succession for user information, product lists, recommendations, notifications, and more.

CDN edge nodes can reuse connections to the origin, reducing repeated TCP and TLS handshakes. But whether you get real benefits depends on whether the origin supports persistent connections, whether the connection pool is well sized, and whether CDN origin connections are stable.

Network path optimization

Some CDN dynamic acceleration products select the transport path from edge to origin based on real-time network quality, bypassing congested or poor-quality public internet routes.

This kind of capability cannot be judged by node maps or product descriptions alone. It must be tested in real user regions, because results may differ by country, ISP, and time period.

Protocol and transport optimization

Users can use HTTP/2 or HTTP/3 to edge nodes, while edge-to-origin transport can use a suitable protocol based on service capabilities. For mobile networks, cross-border links, and environments with packet loss, protocol and connection management can affect request stability.

But a protocol name alone does not prove an endpoint will be faster. If origin application processing takes two seconds, a faster handshake cannot eliminate those two seconds.

Security protection

After APIs are routed through a CDN, you can add the following in front of the origin:

• DDoS protection;

• WAF rules;

• Bot management;

• IP and region restrictions;

• Request rate limiting;

• Anomalous request detection;

• TLS certificate management;

• Origin IP hiding;

• Edge authentication.

These capabilities address security and availability; they are not the same as caching. A payment endpoint is not suitable for caching, but it may still need a CDN's attack resistance and access control.

Which APIs are more suitable for caching

To determine whether an endpoint can enter a CDN shared cache, ask three questions first.

Should the same request receive the same result

If the same request from different users should receive the same response within a certain period, it meets the basic condition for caching.

Common examples include:

• Public article lists;

• News details;

• Product categories;

• Product details that do not include personal pricing;

• Lists of cities, countries, and regions;

• App version information;

• Public campaign configurations;

• Leaderboards with no user-specific differences;

• Statistics that allow brief delay;

• Public file metadata;

• Trending search terms that do not include personal state.

For example:

GET /api/v1/articles/123
GET /api/v1/categories
GET /api/v1/app/version

If these endpoints do not change much within a minute, you can set a shared cache of tens of seconds to several minutes.

Whether the data can tolerate being briefly out of date

Caching means that slightly older data may be returned during the validity period.

If an article takes 30 seconds to reflect an edit, that is usually not a problem; when only one unit of inventory remains, continuing to return the quantity from several minutes ago can cause overselling.

How long stale data is acceptable should be decided by the business, not uniformly set by CDN engineers based on experience.

Whether the response contains user identity or sensitive information

If a response contains any of the following, it cannot enter a shared cache without strict isolation:

• User names, email addresses, phone numbers;

• Login status;

• Order and logistics information;

• Account balance;

• Membership tier;

• Private messages;

• Permission scope;

• Personalized pricing;

• Internal management data;

• Content tied to a token;

• Medical, financial, or other sensitive information.

A CDN is a shared cache. When rules are misconfigured, the most serious problem is not that users see old data, but that user A's response is returned to user B.

Which APIs usually should not enter a shared cache

The following endpoints should generally be excluded by default, unless they have undergone very careful architecture design and security review.

Login, registration, and CAPTCHA endpoints

POST /api/login
POST /api/register
POST /api/send-code

These requests contain credentials, CAPTCHA values, or identity state, and a shared cache must not store and reuse their responses.

User profile and account endpoints

GET /api/me
GET /api/account/balance
GET /api/orders

Even if they use the GET method, that does not mean the response is suitable for caching. The HTTP method is only one criterion; what really matters is whether the content can be shared by different users.

Write and state-change endpoints

POST /api/orders
PUT /api/profile
PATCH /api/cart
DELETE /api/address/123

Requests such as creating orders, updating profiles, modifying shopping carts, and deleting records change server state and should usually go directly to the application service.

Strongly real-time data

For example:

• Payment results;

• Inventory deductions;

• Real-time bidding;

• Flash sale eligibility;

• Transaction prices;

• Risk control decisions;

• Online status;

• Permission change results.

Even if these endpoints use GET requests, data correctness should not be sacrificed to chase hit ratio.

Endpoints whose responses are tied to user identity

Some endpoints have exactly the same path but return different content based onAuthorization, Cookie, or session:

GET /api/dashboard
Authorization: Bearer user-token

If the cache key does not correctly distinguish users, serious information leaks can occur; if the full token is added to the cache key, each user creates a separate cache object, making the hit ratio close to zero and increasing cache management costs.

These endpoints are usually better left uncached, using only dynamic acceleration and security capabilities.

A GET endpoint is not necessarily cacheable, and POST does not mean it cannot pass through a CDN at all

'Cache GET, do not cache POST' can be an initial troubleshooting rule, but it should not be the final judgment.

Most CDNs cache only GET and HEAD responses by default, while POST, PUT, PATCH, and DELETE usually go directly to origin. However, GET requests can also contain private data, real-time data, or one-time results, which likewise must not be shared-cached.

For example:

GET /api/user/profile
GET /api/order/status?id=10001
GET /api/private/download-url

Although they are GET requests, they may still be tied to a specific user or real-time state.

On the other hand, POST requests can certainly pass through a CDN for dynamic acceleration, security inspection, and rate limiting; their responses simply should not be cached without understanding their semantics.

GraphQL is especially easy to misjudge. Many GraphQL queries are submitted to the same POST address, and the request body determines the query content. If a CDN builds cache keys only by URL, it cannot distinguish different queries. Some public requests can be optimized through persisted queries, GET queries, or edge logic, but the query content, variables, identity information, and permission boundaries must be designed clearly.

Do not force complex requests into GET just so GraphQL 'can be cached by a CDN,' while ignoring URL length, sensitive parameters, and cache key security.

How should Cache-Control be set

Whether an API is cached should ideally be explicitly returned by the originCache-Control, not left entirely to CDN guesswork.

Short-term caching for public endpoints

Suppose a public product category endpoint allows CDN caching for two minutes and browser caching for only 30 seconds, you can set:

Cache-Control: public, max-age=30, s-maxage=120

Where:

• publicindicates the response may be stored by a shared cache;

• max-age=30mainly defines the freshness time for client cache;

• s-maxage=120is used for shared caches and usually overrides the shared cache'smax-ageuse.

The specific behavior should also be checked against CDN rules. Managed CDNs may allow the origin response headers to be overridden through the console, so application code alone is not enough.

Private responses should only be stored by the browser

If a response belongs to a single user and should not be shared by the CDN, you can use:

Cache-Control: private, no-cache

Hereprivatemeans the response can only enter a private cache, such as the user's own browser cache, and cannot enter a shared cache such as a CDN;no-cachedoes not mean 'never store'; rather, it must be validated with the server before reuse.

MDN'sHTTP caching documentationspecifically distinguishes private caches from shared caches and explains that personalized responses accidentally entering a shared cache can cause information leaks.

Do not allow any cache to store

For highly sensitive responses or responses that should not be stored, you can use:

Cache-Control: no-store

no-storeonly then means the cache should not store the response.

Many developers conflate the following two directives:

Cache-Control: no-cache
Cache-Control: no-store

They are not equivalent:

For more complete semantics, refer to MDN'sCache-Control documentationand theHTTP caching standard RFC 9111.

How long should API cache duration be set

There is no single TTL that applies to all endpoints.

You can categorize by how stale the data is allowed to be:

A short TTL does not mean absolute safety. Even if cached for only one second, if the cache key ignores user identity, a wrong response may be returned to other users.

The first priority in cache design should be correctness and isolation; hit ratio and speed come second.

What problems can stale-while-revalidate solve

Some public APIs want fast responses and can accept briefly stale data, so you can consider:

Cache-Control: public, s-maxage=60, stale-while-revalidate=30

This means the response in the shared cache is fresh for 60 seconds; within a short window after expiration, stale content can be returned first while the cache is updated in the background.

It is suitable for:

• News lists;

• Public product catalogs;

• Recommended content;

• Public configurations;

• Non-real-time statistics.

It is not suitable for endpoints that must be accurate, such as balances, payment status, and real-time inventory.

You can also evaluatestale-if-error, which returns old public data when the origin is temporarily unavailable. However, different CDNs may support and override these directives differently, so the current official documentation and actual testing should prevail.

Returning stale data is not always better than returning an error. Incorrect prices, permissions, or business status can cause greater losses.

The cache key is the most dangerous part of API caching

After a CDN receives a request, it needs to determine whether it is the same cache object as a previous request. The rules used to distinguish cache objects are the cache key.

Common components include:

• Domain name;

• URL path;

• Query parameters;

• Request method;

• Some request headers;

• Cookie;

• Device or region information.

Query parameters cannot all be ignored

The following requests obviously return different content:

/api/products?page=1
/api/products?page=2
/api/products?page=1&sort=price
/api/products?page=1&category=server

If the CDN ignores all query parameters, they may be treated as the same cache object.

But if all parameters are included in the cache key, the following irrelevant parameters may create many duplicate cache entries:

?utm_source=google
?request_id=随机值
?timestamp=每次变化

A more reasonable approach is to establish a parameter allowlist, so that only parameters that actually change response content enter the cache key.

Amazon CloudFront'squery parameter caching documentationalso recommends configuring cache behavior based on the parameters actually used by the origin, to avoid unnecessary parameter variations reducing cache hit ratio.

Do not casually ignore Authorization and Cookie

Suppose an endpoint returns different user information based on a token:

GET /api/profile
Authorization: Bearer token-a

If the cache key ignoresAuthorization, a response generated by the Token A request may be served as a hit to Token B.

But adding every full token to the cache key is not necessarily a good approach either. It creates many cache objects that can hardly be reused and may increase the risk of exposing sensitive information in logs and debugging systems.

For user-private endpoints, the safer approach is usually not to use a shared cache.

Vary cannot be expanded indefinitely

If a response changes based on language, you can return:

Vary: Accept-Language

This way, different languages form different cache versions.

But if you use:

Vary: User-Agent

Because there are many kinds of User-Agent, cache objects may be severely fragmented. MDN'sVary documentationexplains the relationship between response selection and request headers. In practice, include only request headers that truly affect response content and whose values are relatively controllable.

The most common types of API caching incidents

User A receives user B's data

The usual causes are:

• A private endpoint is set to public caching;

• The cache key ignores identity information;

• Logged-in and logged-out responses use the same cache key;

• A CDN 'cache everything' rule overrides the origin's private caching settings.

This is the most serious type of API caching problem. Before launch, you must cross-test with different accounts, not just check whether your own account works.

Still seeing old results after modifying data

For example, after a user changes an avatar, an admin updates an article, or a product is taken offline, the read endpoint still returns the old cache.

Solutions may include:

• Shorten the TTL;

• Actively purge the corresponding URL after a successful write;

• Use version numbers;

• Separate strongly real-time fields from cacheable fields;

• Indicate data generation time in the response;

• Establish reliable cache invalidation events.

The hardest part is not setting up caching, but ensuring that when data updates, you know which cache objects should be purged.

Different parameters return the same result

This is usually because query parameters did not enter the cache key, or parameter ordering, case, and encoding normalization are inconsistent.

During testing, do not request only one fixed URL. Pagination, filtering, language, region, device, and version parameters should all be verified separately.

Cache hit ratio is very low

Possible causes include:

• Every request carries random parameters;

• The full Cookie or token enters the cache key;

• VaryToo many dimensions;

• TTL is too short;

• Endpoint URL design is unstable;

• Response headers prohibit caching;

• Cache is too dispersed across different nodes.

A low hit ratio does not necessarily mean the CDN is ineffective, but it does mean the goal of 'reducing origin pressure through caching' has not been achieved.

Origin suddenly becomes overwhelmed when a short TTL expires

When popular endpoint caches expire at the same time, many nodes go back to origin together, causing cache stampede or thundering herd.

You can evaluate:

• Adding moderate randomness to cache expiration time;

• Request coalescing;

• Tiered caching or Origin Shield;

• stale-while-revalidate;

• Pre-warming hot endpoints;

• Origin rate limiting and degradation;

• Caching hot data at the application layer.

CDN caching cannot replace the application's own capacity design.

How should dynamic APIs be speed-tested

When testing dynamic APIs, do not mix cache HIT and origin-fetch results together.

At least three sets of results should be established:

1. CDN cache HIT;

2. CDN cache MISS or requiring revalidation;

3. Dynamic requests that are never cached and go back to origin every time.

First check response headers and request latency

You can use curl:

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{response_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://api.example.com/api/v1/categories'

Run it several times in a row and record:

• Response IP;

• HTTP status code;

• Cache-Control;

• Age;

• ETag;

• Vary;

• CDN cache status header;

• DNS, connection, TLS, TTFB, and total time.

If the second request is noticeably faster and the cache header changes fromMISStoHIT, caching may be working. But do not judge by speed changes alone; still combine response headers and origin logs.

Do not use random parameters to test cache hits

If every request adds:

?timestamp=随机时间

and the CDN includes this parameter in the cache key, a new cache object is created each time. What you measure may always be MISS.

When testing HIT, the URL, parameters, and relevant request headers must remain consistent.

When testing whether different parameters are correctly isolated, request separately:

/api/products?page=1
/api/products?page=2
/api/products?page=1&sort=price

Compare response content and cache status.

Use two test accounts to check for data crossover

In an authorized test environment, use account A and account B to request the same private endpoint:

curl -sS \
  -H 'Authorization: Bearer TEST_TOKEN_A' \
  'https://api.example.com/api/me'

Then use account B:

curl -sS \
  -H 'Authorization: Bearer TEST_TOKEN_B' \
  'https://api.example.com/api/me'

You need to verify:

• Whether the data returned by the two accounts is correct;

• Whether private responses appear in cacheHIT;

• Whether the CDN ignores identity information;

• Whether response headers containprivateorno-store;

• Whether the origin logs received the corresponding requests.

Testing must use only dedicated test accounts and temporary tokens. Never write real tokens into public scripts, articles, or logs.

Exclude caching effects when testing dynamic acceleration

To determine whether the CDN's dynamic path is effective, choose endpoints that are explicitly not cached and test separately:

• Users accessing the origin directly or through a dedicated test entry point;

• Users accessing the same origin through the CDN;

• Different regions, ISPs, and time periods;

• Single requests versus sustained requests;

• P50, P95, and error rate.

Do not compare a CDN cache HIT with real-time origin computation; that compares caching with application execution, not dynamic transport paths.

When testing the origin directly, do not expose the real origin IP publicly for convenience. Use restricted test domains, temporary allowlists, or internal probes for the comparison.

Why API speed tests should look at P95, not just averages

Suppose that out of 100 API requests, 90 complete within 200 ms and 10 take more than 3 seconds. The average may still look acceptable, but real users will frequently experience lag.

For dynamic APIs, pay special attention to:

• Success rate;

• P50;

• P75;

• P95;

• P99;

• Timeout ratio;

• 5xx ratio;

• Slowest requests by region;

• Gap between cache HIT and MISS;

• Changes during peak hours.

Averages easily flatten out slow requests. For login, search, form submission, and mobile endpoints, tail latency is usually more important than the single fastest result.

You can useCdnChart website speed testto observe the basic path, TTFB, and availability when accessing API URLs from different regions, then combine application monitoring, CDN logs, and real user data to locate bottlenecks.

For continuous sampling methods, refer to'Website Sometimes Fast, Sometimes Slow: How Should CDN Speed Tests Be Conducted'.

When an API is slow, how do you tell whether it is the CDN or the origin

You can troubleshoot separately by cache status.

HIT is fast, MISS is slow

This indicates edge cache delivery is normal, and the problem is more likely in:

• CDN origin path;

• Origin application processing;

• Database queries;

• Third-party APIs;

• Origin connection pool;

• Cold data loading;

• Cache rebuild.

Both HIT and MISS are slow

You may need to check:

• Whether users are scheduled to distant nodes;

• Network quality from the current ISP to the node;

• CDN node processing latency;

• WAF or edge function time;

• Whether the response body is too large;

• Whether the endpoint has multiple redirects;

• Client-side processing time.

Bypassing CDN is fast, through CDN is slow

This suggests the CDN may add extra path or processing overhead. Focus on checking:

• Node scheduling;

• Origin fetch region;

• WAF rules;

• Edge functions;

• TLS and protocol settings;

• Origin connection reuse;

• Routing from CDN to origin;

• Whether unnecessary request rewriting occurs.

Both CDN and origin are slow

If direct origin access and CDN access are both slow, you usually cannot fix it by adjusting the CDN alone. Continue checking application execution time, databases, cache services, internal RPC, and third-party dependencies.

For related troubleshooting methods, refer to'What causes high TTFB? Should you check CDN or origin first?'.

When choosing an API CDN, which capabilities should be compared

When choosing a CDN for dynamic APIs, do not look only at static file hit ratio.

When WebSocket or gRPC is needed, confirm product support scope first. A CDN supporting ordinary HTTP APIs does not mean all its nodes, plans, and security rules are suitable for long connections or streaming communication.

A safe order for adding dynamic APIs to a CDN

Do not start by enabling 'cache everything' for the entire/api/directory.

A safer implementation approach is:

1. List all API paths, methods, identity requirements, and data sensitivity levels;

2. Classify endpoints into public cacheable, public non-cacheable, user-private, and write operations;

3. By default, do not cache, and enable shared caching only for allowlisted endpoints one by one;

4. Determine the allowed staleness time for each cacheable endpoint;

5. Clearly define how query parameters, headers, and cookies enter the cache key;

6. Set accurateCache-Control,Varyand validation headers;

7. Use different accounts, languages, regions, and parameters for cross-testing;

8. Record performance separately for HIT, MISS, and uncached requests;

9. Establish a cache invalidation process after data updates;

10. Roll out gradually with small traffic and continuously monitor error rate, hit ratio, and origin load;

11. Confirm that no user data, tokens, or private responses enter the shared cache;

12. Then gradually expand to other endpoints suitable for caching.

If the sharing boundary of an endpoint cannot be clearly defined, do not cache it for now. It can still be routed through a CDN for dynamic acceleration and security protection.

FAQ

Will dynamic APIs be cached automatically after passing through a CDN?

Usually, passing through a CDN does not necessarily mean it will be cached. Whether it is cached depends on the request method, status code, response headers, CDN default rules, and custom cache configuration. However, you cannot rely only on default behavior; key endpoints should have explicit cache policies and be verified in practice.

Can API responses returned as JSON be cached by a CDN?

Yes. Whether something can be cached is not directly related to whether it returns JSON, HTML, or another format. The key is whether the response can be safely shared by multiple users and how long it may be out of date.

Can endpoints with Authorization be cached?

Technically, you can design very complex caching strategies, but the risk is high. User-private responses are usually not suitable for shared caching. You cannot simply ignoreAuthorization, and it is not advisable to merge different users' private responses just to improve hit ratio.

Can POST endpoints use a CDN?

They can pass through a CDN for dynamic acceleration, WAF, rate limiting, and DDoS protection, but most CDNs do not cache POST responses by default. Operations such as creating orders, logging in, paying, and modifying data should also not be shared-cached for the sake of speed.

The API is set to no-cache, so why is there still a record in the CDN?

no-cacheIt does not mean it cannot be stored; rather, it must be revalidated before reuse. If you do not want any cache to store the response, evaluateno-store. Also check whether the CDN has custom rules that override origin response headers.

Does a longer API cache duration always mean faster speed?

A longer cache duration may improve hit ratio, but it also increases how long stale data exists. TTL should be determined by the business's data freshness requirements, not simply by chasing a higher HIT rate.

Is dynamic acceleration always faster than accessing the origin directly?

Not necessarily. If users are very close to the origin and the origin's network quality is good, the extra processing layer added by the CDN may not provide clear benefit. Cross-region, cross-ISP, or cross-border access is more likely to benefit, but it still needs to be verified with P50, P95, error rate, and stability from real regions.

After APIs are connected to a CDN, is application-layer caching still needed?

It is usually still needed. CDN caching is suitable for reducing repeated public requests, while application-layer caching can reduce database queries, internal RPC, and business computation. They sit in different places and cannot fully replace each other.

Whether dynamic APIs are suitable for a CDN is not a simple 'yes' or 'no.'

Public, shareable responses that allow brief staleness can be considered for CDN caching; user-private, strongly real-time, and write-type endpoints usually do not enter the shared cache, but they can still use dynamic acceleration and security capabilities. What really needs to be avoided is not dynamic APIs passing through a CDN, but enabling uniform caching for the entire API domain before user boundaries, cache keys, and data freshness are clearly defined.