System requirements

Functional:

• Mutliple types of accounts (standard and vip) vip allows custom urls where standard is randomized
• Must map a long url to a shortened url
• Must have a large capacity of shortened url possibilities
• Url lasts forever unless deleted

Non-Functional:

• Must be highly consistent to prevent two long urls mapping to the same shortened link
• Must be able to handle large scale
• Use a non relational db like mongodb

Capacity estimation

• 26 alphabetic characters(a-z), 10 numeric (0-9) so total amount of possibilities for a character in shortened url is 36
• We will create a max length of 6 characters for the shortened URL since 36^6 = 2176782336. I know this because if we assume 1000 active users per day who each create 2 urls per day on avg. That is 2000 urls created a day. 2000 * 30 * 12 = 720000 urls created a year and if the lifespan of this service was 10 years that is 720000 * 10 = 7.2 million urls which is well below our total possible url combinations.
• 1 url with worst case of 7 digits = 70 bytes
• 70 bytes * 7200000 = 504000000 bytes = 0.504 gigabytes

API design

post createUrl(longUrl,userId, vanityUrl) -> creates a shortUrl

delete deleteUrl(shortUrl,userId) -> deletes a url

update editUrl(shortUrl, customUrl, userId) -> changes a shortUrl based on account status

redirect(shortUrl) -> Directs user to the longUrl when a short url is input

Database design

user{

userId: string,

password: string,

accountStatus: String (basic, premium)

}

url {

urlId: string,

shortUrl: string,

longUrl: string,

userId: string

}

High-level design

1. User logs into account
2. Based on the user's location the load balancer will direct them to the appropriate region for this application
3. User creates a url based on their account status, premium accounts can input a customUrl while regular accounts get a randomly generated id. If a user has a premium account and inputs a vanity url, it will check if it is already taken, if not it will create a url based on the user input
4. Any user that inputs the shortUrl will first check the cache to see if the longUrl is already in there. They will then be directed to the longUrl if it exists in the database
5. If a user wants to delete a shortUrl, they will input the shortUrl and if the shortUrl belongs to their username, it will be deleted

Request flows

createUrl:

1. user generates a random url that the server will make sure doesn't already exist and this new short url will be input into the database
2. user will make their own url and the server will check for if it already exists before committing it to the database

redirect:

1. User inputs the shortened url into their browser
2. This input url will be checked with the cache to see if the longurl is available in there to immediately redirect the user
3. The url shortener will take this short url and check among the database to see if it exists, if it doesn't an error message will be displayed
4. A caching system like redis will cache this url
5. If the url exists, then the service will redirect the user to the long url

Detailed component design

For createUrl there would have to be a check to see if the user has an appropriate account in order to make custom urls.

• We will utilize optimistic concurrency in order to mitigate a race condition of two users inputting the same shortUrl to two different longUrls. If this happens the system will check the state of the database before one user creates the shortUrl and then also after they try to commit it to the database where the two states of the database will be compared before the commit goes through. This will help with large scale usage of the application too since if there is a collision it will display an error message saying to try again if the database state was changed.

Trade offs/Tech choices

• I will utilize a nonrelational database like DynamoDB because consistency and data partitioning is very important for this app. We can sacrifice some availability since we need to account for the possibility of this service to scale with time.
• DynamoDB is a key-value structured database which would make utilizing a hashmaps very efficient for searches. We can implement a hashmap where a shortUrl will point to the information behind it like userId, longurl, etc

Failure scenarios/bottlenecks

• Heavy traffic towards select urls may cause issues

Future improvements

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

• Geoshard by location
• Implement caching on shortUrls that are very popular
• Implement a way to block creation of urls that have profanity