How a redirect answers in 24 milliseconds

The median time between a request hitting our edge and the browser being told where to go is about 24 milliseconds. That number is not an accident, and most of the work behind it was removing things from the path rather than adding them.

The path

A redirect request does five things:

1. Terminate TLS at the nearest of nine edge regions.
2. Look the slug up.
3. Decide whether the link needs anything from the visitor: a password, a consent choice, a safety warning.
4. Choose a destination, which for a plain link is just the one destination, and for a targeted link depends on country, device or language.
5. Send a 302 with the Location header and get out of the way.

Everything else, including the click record, happens after step five.

Lookups come from cache

Every published link is written to the edge cache the moment it is saved, keyed by domain and slug. The redirect service reads from that cache and only falls through to the database when the entry is missing, which happens on a brand-new region or after a cache flush. In steady state the database is not on the request path at all.

The cache entry carries everything step three and four need: whether the link is locked, its targeting rules, its expiry, its click ceiling. So the decision is made from one read.

The click is recorded afterwards

The naive way to count a click is to write a row and then redirect. That puts a database write in front of every visitor. Instead the redirect is sent first, and the request details are pushed onto a queue that a separate worker drains into the analytics store.

The trade-off is a few seconds of delay before a click appears on the dashboard. We think that is the right trade: nobody notices a dashboard that is three seconds behind, and everyone notices a redirect that is three hundred milliseconds slow.

Traffic spikes are absorbed at the edge

Because the hot path is a cache read and a queue push, it scales horizontally without coordination. A link that goes from ten clicks an hour to ten thousand a minute (a launch, a viral post, a badly configured scanner) is served by however many edge workers are needed, and the queue soaks up the burst so the analytics store is never the bottleneck.

Redirects are unmetered on every plan for the same reason: they are cheap enough for us that charging for them would be charging for something that costs almost nothing.

What is deliberately not on the path

• No third-party script. The interstitial pages that need one, like retargeting pixels, are only shown when a visitor has agreed to them.
• No synchronous safety scan. Destinations are scanned when a link is created and re-scanned on a schedule; the redirect only reads the result.
• No session. The redirect route runs without cookies or a session store, which is also why the password form on a locked link does not need a CSRF token.

Where the 24ms goes

Roughly: a couple of milliseconds in TLS resumption, well under a millisecond in the cache read, a millisecond or two in rule evaluation, and the rest in network distance between the visitor and the nearest region. Which means the most effective thing we can do next is not faster code. It is more regions.