Loading...
1) POST API for generating the short url.
2) GET API for getting the short url.
3) Redirect Request
1) Scalable - The system should be scalable enough to handle incoming requests.
2) Availablitiy - The System should be always available.
10% of 1150 is 115 request will be write. And below is the write payload:-
130 url length = 130 bytes
20 extra header = 20 bytes
6 short url = 6 bytes
total storeage needed - 130+20+6=156 bytes
per second storage needed - 115*156 = 17.9 Kb
per day storage :- 17.9 * 60 * 60 *24 = 1.5 GB/Day
per year storage:- 1.5*365=547GB
Storage for 5 Years - 547*5:-2.7 TB
Replica :- 2.7 TB
remaining 1135 req will be read :-
130 url length = 130 bytes
20 extra header = 20 bytes
6 short url = 6 bytes
total storeage needed - 130+20+6=156 bytes
per second storage needed - 1135*156 = 177.9 Kb
per day storage :- 177.9 * 60 * 60 *24 = 15 GB/Day
per year storage:- 15*365=5.475 TB
Storage for 5 Years - 5.475*5:-27.375 TB
Total Storage Needed:- 27.375+2.7=30.075TB
We will needing 3 replica - 30.075*3=90 TB
1) First we will be needing post api for generating url
POST
/short/url
payload:-
{
url:"this is the url"
}
Response:
{
shortUrl:"this is the short url"
}
REDIRECT API
whenever short url hit the user will redirect to original url:-
shortUrl-> get Long Url-> and redirect
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
We will be needing mysql database because the structure is fixed and we need consistency. For storing metadata we can use mongodb.
Because system will read heavy we will use redis for caching and CDN for geographical region devided so that it will faster to redirect.
Below are the table schema:-
User:- containing user basic details
Username
UserId
UserEmail
UserMobile
URLInfo
OriginalUrl
ShortUrl
UserId
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
So high level design will simply has client if they need to store the short url then they can request server and server will return the short url.
If user need to use short url they will hit the short url and short url will redirect to long url.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
So our sequence diagram will contain three component one client who will send the request, server which will handle the request, database will which store the url and get the url.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Our Detailed component design will contain client, server, datasource like redis, mongodb, mysql.
1) Reqeust will come to the server and for hosting the server we will use aws service which is very compatible and through api gateway the request goes to the server and server we will have that many server which can handle that much request.
2) We will have authentication in place if user is valid user and once the user login they need to provide the url and in return they will the short url.
3) If url is repetative then we will use caching on cdn and redis so that it should not be keep hitting the server and we will have failover mechanism if reqeuest fail then server should fetch it from db and return.
4) URL meta we will be keeping in mongodb.
Explain any trade offs you have made and why you made certain tech choices...
Our server will be highly available and will not make any tradeoffs and it can accept any number of request.
Try to discuss as many failure scenarios/bottlenecks as possible.
There is no failover scenarios because when request fail or server is down our service will be hosted in multiple region the request will get redirected to different region or load balancer will redirect the request to healthy server.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
For now our design is able to tackle the current requirement.