System requirements

Functional:

• Service to shorten urls
• Service to parse and redirect urls

Non-Functional:

• Availability: when navigating the shortened url, the original one should be as available as possible to maintain user experience.
• Reliability: Parsing service should be highly reliable, as urls can be used anytime.
• Security: original urls could be private, so there must be a good level of security to restrict access to these url's within the system.

Capacity estimation

100.000 daily users, with an average of 2 shorten requests each. 200.000 requests daily for shortening processes.

For the same amount of users, we will assume they will navigate shortened links 10 times per day as a baseline (1.000.000 daily requests). It is expected that each user will do more parsing requests than shortening ones.

Each shortened url can be created with a maximum of 25 characters (25 bits). A full url, we can allow up to 100 characters (100 bits). That gives us:

• 25 bits per shortened url at 1.000.000 requests = 3.2 mb daily in queries. 100 bits per full url at 1.000.000 responses to those requests = 12.5 mb daily in responses. 15.7 mb in navigation requests daily, 0.00018 mb per second.
• For creating a new shortened url we use a fraction of that, as there are 10 navigation requests per 2 url shortening ones. 15.7 mb / 5 = 3.14 mb per day, 0.000036 mb per second.

For storage of these, we are looking at 15.7 mb daily for parsing requests + 3.14 mb for url shortening requests = 18.84 MB daily. Multiplying that by 30 days, we've got 565.2 MB per month in url storage.

Anticipating annual growth of 25% we've got:

• 565.2 mb per month on the first year = 6.8 gigabytes
• Increase of 25% for the following year = 6.8 + 25% (1.7) = 8.5 Gigabytes on year two.
• 6.8 + 8.5 = 15.3 gigabytes

API design

• POST /v1/generate/alias/
  • Using the UUID from the header request as url id so make the alias unique. Original URL will be sent as a parameter
• GET /v1/parse/alias/{alias}
  • The alias contains a reference to the UUID which will be used to query the original url back.

Database design

We should use a NoSQL type of database, that can allow horizontal scaling. This will be used to store records permanently. Im considering using a cache layer too, with the same data structure to maximise availability when navigating through the alias to the original url.

Each record will hold:

id: UUID from each request

createdAt: Timestamp that can use it for handling cache expiration.

expiresAt: Timestamp which we could use for automatic cache expiration.

url: Original url

alias: shortened url

High-level design

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

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

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?