Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)..
Estimate the scale of the system you are going to design...
POST: /api/v1/submitLongUrl
Request:
{
"originalUrl": "www.randomwebsitesssss.com",
"short_url_id": "abc123". // Optional
}
Response {
Status code: 200
"shortenedUrl": "www.abc123.com"
}
or
Response {
Status code: 400
"error": "User defined URL is already taken."
}
PUT: /api/v1/updateUrl
{
"user_id": "abc",
"short_url_id": "abc123",
"new_url": "abc1"
}
Response {
Status code: 200
"shortenedUrl": "www.abc1.com"
}
or
Response {
Status code: 400
"error": "The new URL you entered is already taken.",
"error": "The short_url_id does not exist or it has expired.",
"error": "The user_id does not match with the user_id that created the short_url_id"
}
POST: /api/v1/redirect
request body{
"originalUrl": ""
}
Response {
Status code: 200 or 404
}
POST: /api/v1/createProfile
{
"username", "password", "DOB"
}
Response {
Status code: 200 or 404
}
GET: /api/v1/getClickedOnTimes
request body:
{
"short_url_id"
}
Response {
Status code: 200 or 404
}
UserProfile
user_id (PK)
password
DOB
location
URL
short_url_id(PK)
user_id
long_url
created_at
expiration_time
clicked_on_time
num_of_clicks
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...
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...
create user account: client -> API gateway -> User Profile Service -> User Metadata DB -> Notification Service -> client
shorten URL request (new short URL):
client -> API gateway -> URL shortening Service -> cache miss -> URL DB (check if the short URL exists, if not then create) -> Notification Service -> client
shorten URL request (already exists):
client -> API gateway -> URL shortening Service -> cache hit -> check if the origin URL is the same, if not return an error -> Notification Service -> client
update URL request:
client -> API gateway -> URL shortening Service -> URL DB -> if the user_id matches and if the new URL is valid -> notification service -> client
client -> API gateway -> URL shortening Service -> Redirect Service -> lookup cache, if miss -> look up the origin URL in URL DB -> if the short URL exists, send the origin URL back to client
view clieck counts and geo location:
client -> API gateway -> Analytics Service -> Notification Service -> client
client -> API gateway -> Geo Service -> Notification Service -> client
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...
API Gateway will serve as a load balancer.
Each service will have a rate limiter.
URL shortening Service will check if the user provided short URL exists in the DB, if not it will insert a short URL to long url mapping into the URL DB. The short URL will be hased using MD5.
DB sharding: consistent hashing that will assign a spot (nearest value thats less than the node) based on the MD5 value and map it on a ring.
DB will evict data based on expiration_time using TTL.
Geo Service will use geo hashing and store the location info into URL DB for tracking purposes.
Analytics Service will use monitoring service like Splunk to track click counts and logging. Redirect will take a shortend URL, look up the URL DB to get the origin URL, and redirect to the origin URL.
Explain any trade offs you have made and why you made certain tech choices...
MySQL for URL DB, lower performance but stronger consistency and relational mapping.
NoSQL for User Metadata DB for scalability and Performance, but no complexy query and less consistency.
Consistent sharding vs hash-based sharding:
Pros:
Con:
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?