The naive version
The first version of AlShorty took one engineer about four days. A hash function, a Postgres table, a redirect endpoint. It worked beautifully in testing. We showed it around, got some excited reactions, and launched quietly. Then someone shared one of our links in a Slack community with 40,000 members. Three hundred people clicked it simultaneously. The database fell over. Links stopped redirecting. It was 11pm on a Thursday.
We fixed it that night with connection pooling and a read replica. But that incident was the beginning of a longer education in what a URL shortener actually is: not a database lookup, but a piece of infrastructure. Every link you shorten depends on AlShorty being fast and available, forever. That's a different responsibility than most web applications carry.
The real problems
People assume the hard part of a URL shortener is the shortening algorithm. It isn't. The algorithm is one function call. The hard parts are: making redirects fast globally — not just in whatever region your server happens to be — collecting click analytics without slowing down the redirect, supporting custom domains reliably, and staying up when your infrastructure has a bad day. We got all four wrong before we got any of them right.
Edge redirects
The redirect path needs to be fast. Not reasonably fast — genuinely fast, in a way that users notice even if they cannot name it. A redirect that takes 400ms feels sluggish. A redirect that takes 20ms feels instant. The difference is almost entirely about where the code runs.
We moved redirects to edge workers — code that runs at data centres close to the user, not in a single region. When someone clicks a shortened link, the request resolves at whichever edge node is nearest, with no round trip to a central server. This brought our median redirect latency from around 180ms to under 22ms globally. That is not a minor improvement. That is the difference between a product that feels professional and one that feels like it runs on a shared server.
“A redirect that takes 300ms feels broken. Edge workers turned that into 18ms — and suddenly links felt instant everywhere.”
Custom domains & SSL
Custom domains nearly broke us. The feature sounds simple: let users point their own domain at AlShorty, and their shortened links use that domain. What's complex is everything underneath. Validating that the CNAME record actually points to us. Provisioning an SSL certificate automatically. Renewing that certificate before it expires without downtime. Handling the case where someone removes the CNAME mid-provisioning, or adds it back days later.
Each of these scenarios, if mishandled, results in a user's links going dead — exactly the kind of thing that generates very unhappy support tickets at inconvenient hours. We had four separate production incidents related to custom domains in our first six months. We now use a queue-based provisioning system with retry logic and explicit failure states, checking certificate validity on every request and triggering a background renewal if expiry is within 30 days. It is not glamorous code, but it is the code that means we have never had a customer email us about a broken SSL certificate since.
Analytics without lag
Every click on an AlShorty link generates an analytics event: timestamp, device, location, referrer. Early versions wrote this synchronously — the redirect waited for the write to complete. Under load, this added 40 to 120 milliseconds to every redirect. Unacceptable.
The fix was to write analytics events to a queue asynchronously and process them separately. The redirect completes in under 20ms. The analytics event lands in the dashboard a second or two later. Most users never notice the slight delay, and those who do tell us they prefer a fast redirect over instant analytics — which is the right order of operations.
What we'd do differently
If we were starting again, we'd separate redirect infrastructure from the application layer from day one, not as a later refactor. The redirect is the product. Everything else — dashboards, settings, billing — is tooling that supports it. That distinction should be reflected in the architecture from the first line of code. We got there eventually, but the migration was painful and we broke things along the way that we shouldn't have broken.
We also learned how much variance there is in DNS propagation times across different regions. Some users would add a custom domain and see it working in minutes. Others would wait hours. We now show a live propagation checker so people have something to look at while they wait, which cut custom domain support tickets by about 60%.
Enjoyed this article?
Get new articles, product updates and insights from Muqira in your inbox.
Found this useful? Share it.
