Redirect caching is a mechanism in which browsers and CDNs store redirect responses (3xx responses) and, on subsequent visits, go directly to the redirect destination without querying the origin server. For URL shorteners, it is a design element involved in achieving both performance and click measurement.
RFC 9110 defines 301 (Moved Permanently) and 308 (Permanent Redirect) as responses that a cache may reuse with a heuristic expiration time even without explicit cache directives (heuristically cacheable), and does not define 302 (Found) and 307 (Temporary Redirect) that way. RFC 9111 leaves the length of the heuristic expiration time up to the cache. While a cached 301 is in use, requests do not reach the origin server and latency goes down, but the URL shortener cannot count those clicks. Responses with 302 or 307 go through the origin every time unless Cache-Control or a similar header specifies otherwise, which makes it easier to record clicks on the server side.
Caching behavior can also be controlled with the Cache-Control header. Under RFC 9111, a response with no-store is not stored in the cache, and a response with max-age=0 is treated as stale right away even if it is stored, so in principle it must be validated with the origin before reuse. Conversely, for redirects that do not need measurement, setting a TTL such as public, max-age=3600 and having the CDN layer cache them can reduce the load on the origin.
Some services also take redirect caching at the CDN into account. CloudFront's documentation explains that it caches 3xx responses according to the distribution settings and the response headers (as of October 2026). While a response cached at the edge is being returned, requests do not reach the origin, so click measurement comes to depend on edge logs.
Designing a URL shortener calls for a Cache-Control design that weighs the trade-off between recording clicks and performance, based on how redirect caching behaves. This means using 301 and 302 for different purposes and controlling the cache TTL.