Engineering
/69 goes where you'd hope
A small, silly feature — a handful of joke links that all point at one profile — turned into a neat lesson about where a redirect actually has to live.
- Published
- Author
- Shubham N Datarkar
- Read
- 4 min
Some features exist because they made us laugh. A short list of vanity links — the internet's favourite numbers, a few winks — that all quietly redirect to one profile. It is a toy. But the toy taught a real lesson about redirects — the kind we write down when the site teaches us something — and the lesson is worth more than the joke, so here it is.
The naive version is easy: catch the slug in the app, and if it is one of the joke ones, send the browser to the real profile. I wrote that, it worked when I clicked around inside the site, and I nearly called it done. Then I typed the link straight into the address bar, the way an actual person sharing a joke would, and got a blank 'profile not found.' The redirect was real and completely useless.
The redirect that only worked if you never arrived
The reason is a detail about how the site is served. Any unknown username is checked at the edge — a layer that runs before the app even loads — and if it does not resolve to a real profile, that layer returns a clean 404 on the spot. It does this on purpose: a mistyped or dead profile URL should be a real 'not found,' not a soft page that pretends to exist and gets indexed forever.
Clicking a link inside a single-page app never reloads the page, so my in-app redirect ran fine. But a typed URL, or a link shared and opened cold, hits the server first — and for these joke slugs the server saw an unknown username and 404'd before the app could run. The redirect lived in the one place that never got a chance to fire for the exact case that mattered.
So the joke slugs were dying at the edge, 404'd as unknown usernames, before the app that knew what to do with them ever loaded. The redirect I had written was only reachable by people already walking around inside the site — precisely the people who would never type /69 into a bar to see what happened.
Put the redirect where the request actually lands
The fix was to move the redirect to where the request first arrives: the edge. Now, before the unknown-username check runs, the edge sees a joke slug and issues a proper redirect to the real profile — for typed links, shared links, crawlers, everyone. The in-app version stays too, for the in-app clicks. Two layers, because there are genuinely two ways to arrive, and a redirect has to live where the arrival happens.
A redirect is only real where the request actually lands. Put it anywhere else and it works only for the people who did not need it.
The bit worth keeping
It is a silly feature with a serious moral, and the moral generalises well past jokes: for anything served at the edge, the edge is the source of truth for a direct hit, and a client-side handler is a convenience for navigation that already got inside. Now the numbers go where you would hope, and the reason they do is the reason worth keeping.
Common questions
Why did a client-side redirect fail for a directly-typed URL?
A single-page app only runs its client routing when you navigate inside it. A typed or shared URL hits the server first — and for an unknown username our edge layer returns a 404 before the app loads, so a client-side redirect never gets a chance to fire.
Where should a redirect for a username-style route live?
At the edge, where the request first lands, so it works for typed links, shared links and crawlers. A client-side redirect is a useful addition for in-app navigation, but it cannot be the only layer.