Putting your API behind a CDN is not mainly about caching — termination, connection reuse and protection pay before a single response is stored. But the caching layer, applied to the right endpoints with the right keys, can absorb a startling share of read traffic. This guide draws the lines.
What the edge buys before caching
Route the API through the CDN with caching fully off and you already collect: TLS termination near the client (handshakes against a nearby edge instead of a distant origin); persistent, multiplexed edge-to-origin connections that strip connection overhead from every call; modern protocol support (HTTP/3's loss resilience helps mobile API traffic disproportionately); and the protection layer — rate limiting, bot filtering, WAF — standing in front of endpoints that are, by definition, mostly uncacheable and therefore expensive to defend at the origin. For many APIs this pass-through configuration is the whole, correct answer, and everything after this section is optional upside. Set the baseline rules accordingly: honor origin cache headers, default to no-store where the origin is silent, never cache POST/PUT/DELETE, and strip or bypass on Authorization until you have deliberately decided otherwise.
Classify endpoints by shareability
Caching decisions are per-endpoint, and one question sorts them: is the response identical for every caller who could request this URL right now? Shared reads — public catalogs, reference data, published content, search over public corpora — answer yes and are cache candidates. Per-user reads — profiles, carts, feeds, anything keyed to the caller — answer no and stay pass-through (edge-cached per-user API data is technically possible via keyed private caching but rarely worth the risk budget). Writes are never cached, full stop. Walk your API's routes and label each; the exercise takes an hour and usually reveals that a handful of shared-read endpoints carry a large majority of total request volume — which is exactly where the next section aims.
Micro-caching shared reads
Shared reads rarely need long TTLs to transform your economics — they need short ones under concurrency. A response cached for even 5–30 seconds collapses a thousand concurrent identical requests into one origin call, which is the difference between an API that survives traffic spikes and one that doesn't; and request collapsing (most platforms coalesce concurrent misses) multiplies the effect at the exact moment it matters. Design the cache key deliberately: include the query parameters that change the response, normalize their order, exclude the ones that don't (client-noise parameters shred hit ratios), and include the Accept/version header if responses vary by it. Add stale-while-revalidate so expiry never shows on the latency chart. The result reads oddly on a dashboard — sub-minute TTLs, enormous origin relief — and it is the highest-leverage configuration in API delivery.
The authenticated-response rules
Authenticated traffic deserves paranoid defaults, relaxed only deliberately. Requests carrying Authorization or session cookies bypass the shared cache — most platforms do this by default; verify rather than assume. Where an authenticated endpoint returns genuinely shared data (a public catalog behind API-key metering, say), you may cache it — but then the key/token must be excluded from the cache key while metering moves elsewhere (a counting layer, or accepting edge hits as unmetered), and origin Vary/Cache-Control: private markings must be consistent, because a single private response cached publicly is the API version of the cart disaster. Test the negative case explicitly in CI: an authenticated response must never be retrievable by an unauthenticated request — one scripted check, run forever.
Invalidation and the trust test
Micro-caching's short TTLs make invalidation forgiving — worst case, wrongness self-heals in seconds — but event-driven purging still earns its keep on endpoints where seconds matter: wire your write paths to purge the affected read URLs (tag-based purging, where supported, maps write-events to cached-response groups cleanly; the platform differences live in the rules engines comparison). Then apply the trust test before enabling any of it in production: for each cached endpoint, write down the maximum staleness a consumer could observe and confirm the product owner accepts that sentence. Monitoring closes the loop — hit ratio per endpoint, origin request rate, and a canary that alerts if a supposedly-bypassed route ever serves a hit, the same leak-detection posture as the security baseline. APIs behind CDNs fail quietly or not at all; the checks are what make it the latter.