Loading...
We should be able to create a shortened link
We should be able to delete a shortened link. In order to delete, it must be done by the person who created it
Links should expire after a given TTL
System should be highly available
Let's assume we get 1 million url shortening requests per month, then the capacity would be 1000000 * 12 * TTL of storage. Assuming it is a TTL of 3 years, we would need to store 36 million records
We need to include 2 API. One of creating a shortened link and one for deleting a shortened link
For the database, we can use a NoSQL database such as dynamoDB as we don't have any requirements that makes us need a SQL database. Databases such as dynamoDB provide autoscaling which helps with availability.
Records in the database, we will store the shortened version of the url as the key, the long url, the user who created the link, and the date of expiry
At a high level, we need a load balancer in order to not overload a server, API gateway for authentication, the server, the service that provides a unique 6 alphanumeric key that will be used for the shortened version of the original link, a database that will store the records from short link to long link.
We can setup a cron job that runs every day to remove all the expired links
For end to end, we start with the clients making a request which first arrives at a load balancer so we don't overload a single server.
For creating the URL, we will have a service of providing a unique 6 digit alphanumeric unique combination. After we call this service, we will store into the database mapping the created url to the original link.
For deleting the URL, we need can add a API gateway layer between load balancers and server so that we can authenticate the user. Once the user is authenticated, we grab the link to be deleted and match the user in the database and the user who requested it. If it is a match, delete the record
When a URL is accessed, we go to the database and grab the link and perform a http 403 redirect to the full link
For the database, we can use auto scaling that is provided by the dynamoDB service. But we can use replication as the paradigm for the database to fulfill the high availability since this service is read heavy
For the service for 6 digit unique characters, we should use an algorithm like base62 encoding so that we do not have collisions. for alphanumeric case sensitive case and length of 6, we have 56^6 i.e. 56 billion combinations of unique identifiers
For database we can use a solution like dynamoDB
In the case that the server goes down, we have horizontal scaling of servers so the load balancer would send the request to a different server instead
In the case of database scaling, because we have replication of databases, we would not run into this issue