Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, high-availability, etc.)...

API Design

1. /get/url: get the long form url behind "url"
2. /shorten/url: store the "url" in the system and return the short form of it

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.

at the heart of this problem, we need 2 components.

1. a key value store to store the shortened urls and upon /get/ requests return their long form.
2. we need a service to generate shorted urls. initially we can just use an incrementor and be like the first url is "a" the second is "b", "c", etc. but this is not ideal since users will be able to easily find other users URLs. like if i have /asdfnm3dc i can do /asdfnm3db or /asdfnm3dd and get other urls. but let's start w/ 1 for now and we'll get to 2 later on.

for now, let's assume that we have the URL incrementor service. we need a key value store (like redis) to store the short-form urls. but also for availability, we will need to have copies of this db for redundancy and high availability.

ok i designed something.

for url shortener: i use a hashing mechanism so that the urls are not easily predictable. the shortener adds sort of a salt to the incoming urls so that the users cannot guess their final urls but also the generation is predictable (on our side) and reuses the same address for the same url.

i assume there is not a big chance for a hash colision but in case two different urls hash to the same thing, i propose the shortener to have a list of multiple salts so that if the first one leads to a colision, use the second, then the third, ... until one salt yield either a shortened url for the incoming url or if there is no corresponding url mapped to it.

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.