Requirements

Functional Requirements:

• There is an UI for the user to enter a URL they would like shortened.
• After the user enters their long URL, they must receive back the short URL in text form.
• The system needs to hold a mapping of short URLs to long URLS
• Short URLs should be randomly generated and not easily guessable
• Short URLs need to be unique and should not be overwritten by newly generated URLs.
• The long URLs should be actual URLs that can be reached.
• Navigating to a shortened URL should redirect the user to the long URL
• Short URLs should redirect to long URLs for as long as the service is still up.

Non-Functional Requirements:

• The short URL should be generated within seconds of the long URL being pasted and the URL generated.
• The system should remain responsive (a couple of seconds for generating and decoding short urls) up to a couple of million URLs being generated. (If we get more than that we'll consider it a good problem)
• The service should have 9.99% reliability.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

// POST API endpoint for generating a short URL. It ingests a long URL, and on success, returns a small URL.

POST generateSmallUrl (longUrl: string): (smallUrl : string)

// GET API endpoint for getting a long URL from a short URL

// Takes in a small URL, and fetches the long URL from the database, and returns it.

GET getSmallUrl (smallUrl: string): (longUrl: string)

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

It is a web app.

Written in HTML

The user opens the web-app in their browser.

They see an input box and a "Shorten" action button.

They enter their long URL.

The long URL is sent to the server.

The server:

• Checks whether the long URL is a valid URL on the internet
• Creates a new, short UUID for it. (start with 5 random alphanumeric)
• Makes a new entry in the Database with the short UUID matching a long URL
• Returns the short UUID to the user in the POST request response.

The user sees the long URL in their browser

When a user navigates to the short url:

• The server considers this a GET response (or is this like a nginx config thing idk)
• The short URL parameter is sent to the GET API.
• If a long URL is retrieved successfully:
  • The API returns a Response.redirect to thew long URL
• If a long URL is not retrieved successfully:
  • The API returns the appropriate error e.g. Not Found
  • This error is shown to the user in the UI

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

SQL database

Access patterns:

• Lots of POST requests to create new tiny URLs
• Some links may see lots of sustained traffic in a short period of time, and then no traffic (e.g. links sent in mass emails, online platforms etc)

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.