Caching redirects at the edge without losing your analytics

The tension in one sentence

A cached redirect never reaches your origin, which is exactly why it is fast and exactly why you cannot count it. Every caching decision for a link platform is a trade between latency and observability, and the right answer differs per link.

What browsers do with each status code

A 301 or 308 is permanent and browsers may cache it indefinitely, sometimes ignoring cache headers entirely. A 302 or 307 is temporary and is normally re-requested. This is why marketing links should default to temporary: the moment a client caches a permanent redirect, you have lost both the ability to change the destination and the ability to see the click.

Cache the lookup, not the response

The good pattern for a link platform is to keep the destination lookup in memory close to the user while still executing the request at the edge, so the click is recorded and the response is generated fresh. That gives sub-50ms responses without giving up the log entry, and it makes destination edits propagate as fast as your invalidation.

Invalidation strategy determines edit latency

A time-based TTL of a minute is simple and means edits take up to a minute to appear everywhere. Explicit invalidation on write is faster but needs a reliable fan-out to every edge location. Whichever you choose, state the expected propagation time in your documentation, because the first support question after any edit is "why is it still going to the old page".

Vary carefully when links are targeted

Geo-targeted or device-targeted links produce different responses for different visitors. If anything in the path caches by URL alone, some visitors get another region's destination. Either mark those responses uncacheable or ensure the cache key includes the dimensions you target on. Getting this wrong produces a bug that is invisible in testing and obvious to customers.

Be explicit in cache headers

Do not rely on defaults. Send explicit Cache-Control on redirect responses, and prefer no-store for anything targeted or measured. Intermediate proxies in corporate networks make their own decisions in the absence of instructions, and those decisions will not match yours.

Measure from the outside

Synthetic checks from several regions that record the time to first byte on the redirect itself, separately from the destination, are the only way to know whether your caching is doing what you think. Internal timings from the origin will look excellent regardless of what visitors experience.