How we keep redirects fast, globally

A redirect is the most latency-sensitive thing a link platform does, and it's easy to underestimate. Every extra millisecond between the tap and the destination is a moment where a distracted person on a train can change their mind. Slow redirects don't just feel bad; they quietly cost you conversions. Our aim is a consistently fast median redirect, measured anywhere in the world. Here's how we get there and, just as importantly, how we keep it there under load.

Keep the hot path tiny

The single most effective decision was ruthlessly minimising what happens on the redirect path itself. When a click arrives, we do only three things: resolve the short code, decide the destination, and respond with the redirect. That's it. No synchronous writes, no external calls, no heavy computation between the request and the response.

Everything else that's valuable but not essential to the redirect — analytics enrichment, geolocation, device parsing, bot scoring — is deferred. The visitor is already on their way to the destination before any of that work begins. Latency is a budget, and we spend almost all of it getting the person where they're going.

Cache first, database second

Short codes and their routing rules live in a layered cache: an in-process memory cache backed by Redis. On startup we warm the cache with the busiest links, so the most-clicked codes are hot before the first request of the day. A typical resolve is a memory read measured in microseconds, not a database round-trip measured in milliseconds.

The database remains the source of truth — it's where writes go and where the cache refills from — but it's deliberately kept off the hot path. Cache invalidation happens when a link changes, so edits show up promptly without making every redirect pay the cost of a query.

Process clicks asynchronously

When a click lands, we enqueue a compact event and return the redirect immediately. A pool of background workers then does the interesting work: country and city from a maintained geo database, device and browser from the user agent, bot and VPN scoring, and finally a durable write for your analytics.

This is the trick that lets us have it both ways. Your analytics stay rich and accurate — geography, devices, referrers, quality scoring — while the person clicking never waits for any of it. The queue also absorbs traffic spikes gracefully: a viral link floods the workers, not the redirect path.

• Three-step hot path: resolve, decide, redirect
• In-memory plus Redis cache, warmed on startup
• Geo and device enrichment moved off the critical path
• Async click pipeline with a worker pool and durable writes
• A global edge so the response is physically close to the visitor

Measure where it matters

Averages lie, so we watch the median and the tail. A great median with an ugly 99th percentile still means some real people had a bad experience. We monitor redirect latency by region and alert on the tail, because "fast on average" isn't the promise — "fast for the person clicking" is.

The best redirect is one nobody notices. If we've done our job, the click feels instantaneous and the analytics are still complete.

None of this is exotic. It's the disciplined application of a few old ideas — cache aggressively, do the minimum on the critical path, and push everything else into the background. Applied consistently, they add up to a redirect that feels instant and an analytics record that's honest.