System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)..

1. a user can submit a long url and get a shortened url back.
2. a shortened url will redirect to the origin url
3. how many times the shortened url is clicked on
4. tracking the geo location the user is clicking from
5. authentification, the user can create an account and view analytics

Non-Functional:

1. highly scalible
2. highly available
3. low latency
4. real-time analytics

Capacity estimation

Estimate the scale of the system you are going to design...

1. 100,000 daily users, peak traffic 300, 000
2. daily shortening requests 5 * 100,000 = 500,000
3. redirect requests 10 * 100,000 = 1,000,000
4. url size (300 bytes) * 500,000 = 150 mb

API design

POST: /api/v1/submitLongUrl

request body:

{

"originalUrl": "www.randomwebsitesssss.com",

"short_url_id": "abc123"

}

return {

"shortenedUrl": "www.abc123.com"

}

POST: /api/v1/redirect

request body{

"originalUrl": ""

}

POST: /api/v1/createProfile

{

"username", "password", "DOB"

}

GET: /api/v1/getClickedOnTimes

request body:

{

"short_url_id"

}

Database design

UserProfile

username (PK)

password

DOB

websites

location

URL

short_url_id(PK)

long_url

created_at

expired_at

clicked_on_time

High-level design

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...

Request flows

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:

client -> API gateway -> URL shortening Service -> URL DB -> Notification Service -> client

view clieck counts and geo location:

client -> API gateway -> Analytics Service -> Notification Service -> client

client -> API gateway -> Geo Service -> Notification Service -> client

Detailed component design

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...

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.

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.

Trade offs/Tech choices

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.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

1. db might get overloaded since theres only one db for shortening service as the user base becomes larger.
2. The client will experience latency if the geo location is far from the server.
3. Lack of message queueing, the system will get overloaded as the scale becomes larger
4. Single point of failure: if the API getway goes down, the whole system will not be able to take user requests, also the DBs.
5. If one of the services goes down, the user will not be happy.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

1. add CDN
2. add message queues for URL shortening service and notification service to buffer the workload
3. add worker DBs as read-only DBs that will have the same exact data as the master db, and only write data to the master DB.
4. Add more load balancers and API gateways to horizontally scale.
5. Caching for URL shortening service, so when the user submits the same request, it request wont make it all the way to the server.