Loading...
The url should be shortened by some algorithm
They should have expiry time ~10 years
The system will be read heavy
1000 requests per second
DB storage: 100 bytes * 1000 * 3600 per day ~ 3.6*10^8 = 3.6*10^2 MB
3.6*100*360 per year
~ 216+1080 = 1296 ~10^3
10^3*10^2 = 10^5 MB per year
100 GB per year
We will create REST APIs:
POST myservice.com/generate_url?api_key={api_key}
Body (json)
{
"url": "
}
Response
{
"shortUrlKey": "
}
GET request on shortened url should resolve to the original url
Example will be:
GET myservice.com/s/
I would say we can use Relational Database like SQL server to store mapping between original url and shortened url
The key will be the shortened-url-key.
Let's create two microservices, one for creating the shortened url and other to resolve the url
A load balancer can be used to route the correct microservice
For database we will have:
Write replica
Multiple read replicas
generate url microservice can be used to write on the DB
While read replicas will be used by the other microservice
Caching can be used for example by Redis in microservice 2
Request goes to appropriate microservice using load balancer and response is returned
Algorithm: we need the shortened-url-key to be URL safe, hence base64 is a good choice.
We do not need to encode the information, instead we will map with a unique URL safe key which we will generate on the Database side. Let's generate UUID and then encode it using base64
secondly we should keep separate entries in Database if different users try to shorten the same url, for monitoring purposes. Different users can monitor it differently and get the analysis of where/who/why clicked it (if possible)
Relational vs Non-relational DB can be chosen, but choosing relational DB is much more easy and it will be able to handle the load and hence no need to choose NoSQL
If one read replica fails then we can use another one
If caching server is down, we can directly query the server
Future improvements can be done to have monitoring and analytics implemented