How i built a super fast short link redirection system
Overview
In a URL shortner system there are read to write ratios of about 1000:1 approximately. This ratio might get even more skewed as the service becomes popular.
So, to build a super fast sytem we need to tackle read and write parts. I chose to tackle them seperatly. In this article we will only focus on URL redirection part of the system, which deals with read aspects only.
When building a URL redirection system, we need to have:
- server instances that connect to database or a cache
- server instances can be always running instances or serverless instances
- these instances can be in one region or in multiple regions
Challenges
There is cost and latency associated with having server instances for resolving short URL to original.
Having always running server instances adds up to the cost. Alternatively choosing serverless instances is not a wise option for read related work. With a serverless instance there is a startup time and database connection establishment latency to consider. For new service with less volume, this latency will hamper service's percieved performance.
I wanted to bring down the latency of each request to about 50ms to 100ms no matter where the user is accessing the short link from while keeping the cost of running this sytem to minimum.
Solution
To address this cost and latency challenges, I came up with a way which can reduce the cost dramatically and bring down latency to 50ms to 100ms no matter the region or load on the overall system.
So instead of relying on server instances and maintaining these across multiple regions, we can use static html files to perform the redirection. Each short URL say smlr.io/abcd1234 will have a route within the system, that will have a corresponding HTML file abcd1234.html which contains the original link and script to use this link for redirecting the user to it.
With this we dont necessarily have to rely on a redirect response from a service. We can maintain a seperate service which returns redirect response if needed under a subdomain api.smlr.io. This is with the assumption that you have more users directly accessing the short URLs when compared to api clients working with your service.
Code Sample
A sample html for a short URL page might look like this:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<script>
window.location.href = "https://open.spotify.com/artist/06HL4z0CvFAxyc27GXpf02"
</script>
</body>
</html>
But in case you have a link with certain settings that needs evaluation at runtime say, redirect based on region, you can have a different script embed for it:
<script>
fetch("api.smlr.io/abcd1234")
</script>
Advantages
Now we know how redirection will be done, so lets focus on what are the advantages of this architecture and challanges that needs to be addressed.
Latency
Accessing static html files have a very fast response time. The resonse might depend of the provider your choose but can be roughly in the range of 20ms to 100ms.
Caching
Also, these static files can be cached across the globe.
Scale
Distributing the static files is much easier that spinning up server instances across regions and managing scaling to handle reads volume at scale.
Challenge
If you go with static html route for your read needs, you will still need a way to establish analytics data gathering. And again you will have very little time window to do so. So, you cannot load a full fledged analytics library here.
I opted for building a inhose api service, that i hit before redirecting.
Hiting the analytics service
One challenge here is, if you do a simple api call, as soon as the script for page redirects executes a page redirect will happen instantly and the api call made to analytics service would get cancelled. And this api call would never reach the api server.
So, we have to rely on good old navigator.sendBeacon function. This is meant especially for making analytics call and even when the redirect is done on the client side, the browser would ensure the api call is completed in the background.
<script>
navigator.sendBeacon("api.smlr.io/analytics/abcd1234")
window.location.href = "https://open.spotify.com/artist/06HL4z0CvFAxyc27GXpf02"
</script>
NOTE: Only POST api call is supported when using navigator.sendBeacon.
Alternatively, instead of building inhouse service you could integrate with a analytics service on your backend.
More Articles
Recommended tsconfig settings For Nextjs 14
Recommended tsconfig settings for Nextjs 14
03/10/2024
Understanding the Difference Between Platform and Infrastructure Teams
Difference Between Platform and Infrastructure Teams
10/10/2024
Shell Programming Basics With Examples
Here is a small introduction to the basics of Shell Programming
16/08/2024
A Comprehensive Guide to understanding JWT Tokens
What is a JWT Token and how it works
22/07/2024