System requirements

Functional:

• Reads a URL
• Stores the original URL for record keeping and redirection
• Links the original URL into a shortened one
• Reads a shortened URL and redirects the user to the original destination
• User management (optional for the user)
• Sign up
• Sign in
• Views previous shortened url's
• deletes previous shortened url's

Non-Functional:

• High availability and performance when using a shortened url quickly redirect to the original url.a
• Strong consistency: a shortened url should be able to point to the original url no matter what
• Security: in case a user stores a url that points to sensitive information.

Capacity estimation

For the user service we are talking about unlimited users. Bear in mind, not everyone will sign up for the service, most users would probably just use the shortening url service. So we need a database that should be able to scale vertically. We can start assuming that 100k users would be the first iteration, and based on how the product gets adopted.

Writing should be a fairly congested operation. If we have 100k users, averaging between 5 to 20 writes per month, then lets aim for 200k writes per month, to have capacity for power users.

Reading though, that should be even more. Users will enter a URL just once, and this will generate a shortened one that will be read many times (normal reads, browser refreshing, rage refreshing). If we are talking about 100k users, averaging 20 reads per month as a baseline, then that makes it 2.000.000 reads.

API design

v1/users/signup

Sends

• email
• password
• region - taken from the frontend's locale
• userId - assigned by the system when successful request

v1/users/login

Sends

• email
• password

Returns

• sessionToken
• userId

v1/users/getAccount

Sends

• userId

Returns

• [urls]
• urlId
• full
• shortened
• expiration

v1/urls/generate

Sends

• userId?
• url

Returns

• shortenedUrl

Database design

Users should be stored depending on their region, as different regions might have different privacy laws. we can shard the user db per region for future scaling implications.

User

• userId
• email
• password
• region

Session

• userId
• token
• 
  

Url

• requestId
• fullUrl
• shortenedUrl
• expirationDate

Account

• userId?
• [urls]

High-level design

• User service to handle account creation
• Load balancer that will handle writes and reads on the users db. Used for signups and user data reads
• Users database
• A sessions cache, that will temporarily hold a user session. To retrieve user data, it will query the db through the users load balancer
• Url shortener service, will hold the business logic that will take a url and assign a newly generated shorter one.
• Url load balancer that handles writes and reads from the URLs database
• A Url database
• A redirect cache, that will hold a record of the original and the short url for better performance when redirecting.
• An asynchronous updater that will keep the cache updated and/or will expire the url

Request flows

Detailed component design

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

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

Future improvements

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